Cloud Operations re:Invent 2023

Building a multi-account, multi-runtime service-oriented architecture (sponsored by HashiCorp)

マルチアカウント、マルチランタイムサービス指向アーキテクチャの構築（HashiCorp主催）

Pulisher : Cloud Technology Center イ・ギョンソン
Description : Hashicorpのサービスを使ってマルチアカウント、マルチランタイムマイクロサービスアーキテクチャを設定する方法について紹介したセッション。

はじめに

HashiCorpはこの度、AWSのグローバルコラボレーションパートナーオブザイヤーに選ばれました。今年のコラボレーションパートナー賞は、AWSおよび他のAWSパートナーと協力して、複数のAWSパートナーが提供するサービスや技術を活用して顧客の問題を解決したパートナーに贈られる賞です。

参考リンク : https://www.hashicorp.com/blog/hashicorp-at-re-invent-2023-a-year-of-collaboration-with-aws

それにふさわしく、ハッシュコープのソリューションの中で最も多く聞いたことがあるクラウドインフラストラクチャ自動化IaCツールであるテラフォームで最も多く使うプロバイダーはAWSであり、20億ダウンロードされるほど、AWSを使う人が多く使うソリューションです。

参考リンク : https://aws.amazon.com/ko/blogs/aws-insights/two-billion-downloads-of-the-terraform-aws-provider-shows-value-of-iac-for-infrastructure-management/

また、私たちメガゾンクラウドが韓国唯一のハッシュコープの総販会社であることをご存知でしょうか？実際のプロジェクトでの協業を通じて、私自身も実務で小さなワークロードから大きなワークロードまでテラフォームをたくさん使っています。規模が大きくなり、セキュリティ規定によって複数のアカウント、複数の環境、複数のリージョンへの構築のためには自動化が必須の部分です。いつも関心があった部分なので、このセッションを申し込みました。

セッションの概要紹介

multi account, multi runtime, multi regionサービス指向のアーキテクチャのために、AWS環境でHashicorpのソリューションをどのようにうまく組み合わせて使うかについてのインサイトを共有するセッションです

multi account, multi runtime, multi region環境でのサービス指向アーキテクチャを構築することは非常に多くの悩みが必要な部分です。

組織には様々な技術と様々な希望を持つ非常に多くの人々がいて、この人々はそれぞれのプロセスを使用して業務を行います。そのプロセスに対する一貫性がないため、全員が同じことを知らないだけでなく、このすべてを学ぶ時間がないため、一貫性のある自動化について絶えず考え、努力しています。

今回のセッションでは、Cloud環境上でサービスとインフラをプロビジョニングして構成するプロセスを提供し、既存のシステムを拡張し、多くの人が望むものをより多く構築できる能力を提供するために、HashiCorpツールを使ってセキュリティと自動化ができる部分について説明します。

全体的な参考リンク : https://github.com/jcolemorrison/foundational-soa

サービス指向アーキテクチャの最初の段階から説明すると、講演者はサービス指向アーキテクチャの定義は決まっていないと述べましたが、その代わりに、そのアーキテクチャを作成する際に従うべき4つのガイドラインとマイルストーンを定めました。

１．自律性

それぞれが全て独立していて、中断することなく変更可能でなければなりません。まるでブロックのように、作成し、使用するコードとモジュールが依存関係なく自力で作業できるようにすることです。

生のプラスチックですべてを作るのではなく、ブロックを作り、それで建築を始めるのです。

２．標準化

自動化は一貫性があるときに最もよく機能するため、標準化が重要です。

特定のいくつかのケースにより、自動化が中断されることが多いため、これらすべての標準化が鍵となります。共通のフォーマット、プロトコル、ルールを使用し、守らなければなりません。つまり、少なくとも何らかの共通のフォーマットを設定する必要があります。

自動化がある程度一貫性を持つようになり、そうなれば極端なケースが発生しなくなります。そして、標準化の場合、まるで建築に使用する様々なタイプのレンガを持つようなものです。

３．ゆるやかな結合

標準化により様々なタイプのレンガがあり、これに対するレンガを連結するために必要なものが必要です。

ゆるやかな結合は、そのレンガを他の部分と接続できるようにするstudsとpipsと考えることができます。このようにレンガを分解して他のものと一緒に再利用できるのがゆるやかな結合の原理です。だから、よく定義されたインターフェースが必要です。例えば、コードモジュール、サービスなどを使用できる非常によく定義されたAPIのようなものです。

４．検索可能性

大規模なシステムには多くのリソース、コンポーネント、資産があります。セキュリティと自動化の観点から、これらを追跡し、何が起こっているのかを特定することは非常に困難です。

したがって、各コンポーネントの一部として識別された明確な目的があることを確認し、そうでない資産に関するすべての情報を手動で確認して調整することができないため、つまり、システムのすべてを追跡することができないため、文書化して迅速な検索ができるように設計する必要があります。

上記4つのガイドラインを基に、マルチアカウント、マルチruntime及びマルチ地域でのインフラ構築についてデモデモ映像を見せた部分です。

(迅速なデモ映像に集中するため、写真が少し不足しています)

マルチアカウント、マルチruntime、マルチリージョンの3つのセクションに分かれてそれぞれのインフラ構築の場合、ハッシュコープのどのようなソリューションとAWSのどのようなサービスを組み合わせて使うかについての内容でした。

githubリンク : https://github.com/jcolemorrison/foundational-soa

AWS Organizationを通じて、Root Mgntアカウントと一緒に使っているruntimeを表すサブアカウントで分離して使用しました。このデモはgithubのrepository構造でOrg Hierarchyを設計しました。

また、様々なランタイムを表す様々なサブアカウントに分離することで、ECS runtimeを使うワークロードに対するものは全てECS Accoutにマッピングし、EKSもEKS Accountにマッピングし、それぞれ、そのアカウントでのみ作業を実行できるように設定しました。

Terraform Cloudを通じて、githubにコードをコミットするたびにTFC環境に変更事項が適用されてプロビジョニングされる構造です、

TFCの構造もAWS Accountよりもっと細分化が可能で、事業部が多ければProjectの形でも可能で、ビジネスユニット別にワークスペースを分けて使用した部分を紹介しました。

当該Terraform cloudとAWS間のAccess方法は、AWS IAMでDynamic credentialを通じてrole basedでアクセス制御が可能です。

AWSのGlobalインフラとregionalサービスなどTerraformのコードやモジュールを通じてMulti region環境により簡単に展開するための方式も説明してくれました。

(EKSランタイムに関して、該当repoに修正がある時に反映されるEKS専用TFC環境)

(それぞれの基準によって分離されたTFCプロジェクト、ワークスペース)

AWS IAM OIDC Dynamic credential設定方法

参考リンク : https://developer.hashicorp.com/terraform/tutorials/cloud/dynamic-credentials

観察、測定、管理モニタリングに関する部分です。

Terraformを使ってMulti account環境にAWS Cloudtrailをプロビジョニングした後、どんなAPIイベントが発生したか確認することができます。

そのlogsについてcloudwatch logsにロードして、その情報もConsulのコンソールでダッシュボードの形で表示する部分まで示しました。

この部分は、任意にコンソールでECSクラスターの一つをわざと障害させて、TFCコンソールで再配布して簡単に修正したり、機能を追加することができるデモシーンでした。

コンソールでクリッククリックしながらインフラを構築した時と違ってTerraform cloudを使うなら、そのコードをプロビジョニングする時に発生するリソースに対する部分を事前に確認することができ、この時、バグがあればプロビジョニングせずにそのコードを修正して再検討してデプロイすることができます。このようなことをUIの形で提供してより高い可視性を持つことができます。

最後にユーザーアクセスのセキュリティについて、

よくAWS環境で、private subnet上に置いたEC2に対して接続するためにpublic環境のSSH Bastionサーバーへの接続が必要です。この時、Boundaryソリューションを通じてアカウント情報管理やネットワーク露出なしに安全にリモートホストに接続する例を紹介しました。

セッションを終えて

Terraform、Terraform Cloudは普段から接した経験があるため、より簡単にディープダイブした内容を理解することができるきっかけになりました。 terraform以外にも、最近興味を持ち始めたVaultから始まり、名前だけ聞いたことがあるサービスマッシュサービスであるConsulから始まり、Boundary、Hashicorp Cloud Platform (HCP)まで接することができる機会でした。

AWSは今やAWS Nativeサービスだけでなく、ますます多くの他ソリューションとの連動が可能になり、従来より良いシナジーを出すことができるようになりました。ますます増えているMulti account, Multi runtime, Multi region環境構築に対するニーズに対して、より良いサポートを提供できるインサイトを得ることができるセッションでした。

最後に要約と参考リンクを共有します。