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を使う人が多く使うソリューションです。実際のプロジェクトでの協業を通じて、私自身も実務で小さなワークロードから大きなワークロードまでテラフォームをたくさん使っています。規模が大きくなり、セキュリティ規定によって複数のアカウント、複数の環境、複数のリージョンへの構築のためには自動化が必須の部分です。いつも関心があった部分なので、このセッションを申し込みました。region環境でのサービス指向アーキテクチャを構築することは非常に多くの悩みが必要な部分です。組織には様々な技術と様々な希望を持つ非常に多くの人々がいて、この人々はそれぞれのプロセスを使用して業務を行います。そのプロセスに対する一貫性がないため、全員が同じことを知らないだけでなく、このすべてを学ぶ時間がないため、一貫性のある自動化について絶えず考え、努力しています。今回のセッションでは、Cloud環境上でサービスとインフラをプロビジョニングして構成するプロセスを提供し、既存のシステムを拡張し、多くの人が望むものをより多く構築できる能力を提供するために、HashiCorpツールを使ってセキュリティと自動化ができる部分について説明します。https://github.com/jcolemorrison/foundational-soaサービス指向アーキテクチャの最初の段階から説明すると、講演者はサービス指向アーキテクチャの定義は決まっていないと述べましたが、その代わりに、そのアーキテクチャを作成する際に従うべき4つのガイドラインとマイルストーンを定めました。1.自律性それぞれが全て独立していて、中断することなく変更可能でなければなりません。ブロックのように、作成し、使用するコードとモジュールが依存関係なく自力で作業できるようにすることです。生のプラスチックですべてを作るのではなく、ブロックを作り、それで建築を始めるのです。自動化は一貫性があるときに最もよく機能するため、標準化が重要です。特定のいくつかのケースにより、自動化が中断されることが多いため、これらすべての標準化が鍵となります。共通のフォーマット、プロトコル、ルールを使用し、守らなければなりません。少なくとも何らかの共通のフォーマットを設定する必要があります。自動化がある程度一貫性を持つようになり、そうなれば極端なケースが発生しなくなります。標準化の場合、まるで建築に使用する様々なタイプのレンガを持つようなものです。標準化により様々なタイプのレンガがあり、これに対するレンガを連結するために必要なものが必要です。ゆるやかな結合は、そのレンガを他の部分と接続できるようにするstudsとpipsと考えることができます。このようにレンガを分解して他のものと一緒に再利用できるのがゆるやかな結合の原理です。定義されたインターフェースが必要です。コードモジュール、サービスなどを使用できる非常によく定義されたAPIのようなものです。大規模なシステムには多くのリソース、コンポーネント、資産があります。セキュリティと自動化の観点から、これらを追跡し、何が起こっているのかを特定することは非常に困難です。したがって、各コンポーネントの一部として識別された明確な目的があることを確認し、そうでない資産に関するすべての情報を手動で確認して調整することができないため、つまり、システムのすべてを追跡することができないため、文書化して迅速な検索ができるように設計する必要があります。上記4つのガイドラインを基に、マルチアカウント、マルチruntime及びマルチ地域でのインフラ構築についてデモデモ映像を見せた部分です。(迅速なデモ映像に集中するため、写真が少し不足しています)マルチアカウント、マルチruntime、マルチリージョンの3つのセクションに分かれてそれぞれのインフラ構築の場合、ハッシュコープのどのようなソリューションとAWSのどのようなサービスを組み合わせて使うかについての内容でした。Mgntアカウントと一緒に使っているruntimeを表すサブアカウントで分離して使用しました。Hierarchyを設計しました。Accountにマッピングし、それぞれ、そのアカウントでのみ作業を実行できるように設定しました。Accountよりもっと細分化が可能で、事業部が多ければProjectの形でも可能で、ビジネスユニット別にワークスペースを分けて使用した部分を紹介しました。basedでアクセス制御が可能です。region環境により簡単に展開するための方式も説明してくれました。https://developer.hashicorp.com/terraform/tutorials/cloud/dynamic-credentials観察、測定、管理モニタリングに関する部分です。Cloudtrailをプロビジョニングした後、どんなAPIイベントが発生したか確認することができます。logsにロードして、その情報もConsulのコンソールでダッシュボードの形で表示する部分まで示しました。この部分は、任意にコンソールでECSクラスターの一つをわざと障害させて、TFCコンソールで再配布して簡単に修正したり、機能を追加することができるデモシーンでした。cloudを使うなら、そのコードをプロビジョニングする時に発生するリソースに対する部分を事前に確認することができ、この時、バグがあればプロビジョニングせずにそのコードを修正して再検討してデプロイすることができます。このようなことをUIの形で提供してより高い可視性を持つことができます。Bastionサーバーへの接続が必要です。この時、Boundaryソリューションを通じてアカウント情報管理やネットワーク露出なしに安全にリモートホストに接続する例を紹介しました。Cloudは普段から接した経験があるため、より簡単にディープダイブした内容を理解することができるきっかけになりました。(HCP)まで接することができる機会でした。Nativeサービスだけでなく、ますます多くの他ソリューションとの連動が可能になり、従来より良いシナジーを出すことができるようになりました。region環境構築に対するニーズに対して、より良いサポートを提供できるインサイトを得ることができるセッションでした。最後に要約と参考リンクを共有します。