AWS Proton が GA したのでやっていきましょう Part.1 (座学編)
はじめに
AWS Proton が GA しましたね。
上記ブログに記載がある通り、プラットフォームエンジニアと開発者、日本風に言うと「インフラ担当」と「アプリ担当」が明確に分かれている組織を想定したサービスです。
日本のエンタープライズ系の企業では、職能ベースでこういった組織構成になっていることが多く、そういった企業に対するゲームチェンジャーになり得る AWS サービスではないかと個人的には期待しています。
まずは AWS Proton の用語やコンポーネントを理解していくところからやっていきましょう。
登場人物
さて、ここで登場人物を整理しましょう。
上記ブログでは「プラットフォームエンジニア」「開発者」という言葉を使っています。実際に AWS Proton のドキュメントは 2 つ用意されています。
登場人物は大きく分けて 2 つです。
- 管理者 (図の左側)
- インフラ担当
- ドキュメント上ではプラットフォームチームとも記載されている
- ユーザー (図の右側)
- アプリ担当
- ドキュメント上では開発者とも記載されている
私はどちらかというとインフラ側が得意な人間ですが、インフラ担当が「管理者」で、アプリ担当が「ユーザー」というのはちょっと違和感があります。例え組織が分かれていても共に同じサービスを作って行くチームの一員だと思っているからです。
また、AWS Proton は AWS サービスですから、結局のところは IAM 権限さえあればどんな操作でも可能であることに注意が必要です。
したがって、この記事では便宜上「インフラ担当」「アプリ担当」という言葉を使っていくことにします。
インフラ担当のお仕事
AWS Proton を利用する環境において、インフラ担当のお仕事は下記の 3 つです。
- 「環境テンプレート」を作成し、AWS Proton に登録する
- 「環境テンプレート」を利用し、1 つ以上の「環境」をデプロイする
- 「サービステンプレート」を作成し、AWS Proton に登録する
ここで「環境テンプレート」「サービステンプレート」「環境」という 3 つの AWS Proton 用語が出てきました。これらの用語について解説していきます。
環境テンプレート
環境テンプレートは、様々なアプリケーションから利用される共有リソースを定義したものになります。分かりやすい例としては VPC やサブネットのようなネットワーク関連のリソースがこれにあたります。
実態としては下記の 3 つのファイルから構成されています。
- scheme.yml (スキーマファイル)
- 環境固有のパラメーターを定義しています
- 例
- VPC やサブネットの CIDR など
- manifest.yml (マニフェストファイル)
- 下記の内容が記載されています
- CloudFormation テンプレートのファイル名
- レンダリングエンジン (現時点では Jinja 固定)
- テンプレート言語 (現時点では CloudFormation 固定)
- 下記の内容が記載されています
- テンプレートファイル
- 現時点では CloudFormation + Jinja のみ
- CloudFormation は SAM 形式も利用可能です
まず、環境固有のパラメーター、つまりカスタマイズ可能な値をスキーマファイルで定義します。この環境固有のパラメーターはレンダリングエンジン (テンプレートエンジンともいう) を通して、テンプレートに渡されます。
レンダリングエンジン (テンプレートエンジン)は Python プログラマーにはお馴染みの Jinja が使われています。どういうものか分からないという人は Jinja の紹介ページをご覧ください。
そして、マニフェストファイルでは、レンダリングエンジン・テンプレート言語を指定します。
テンプレートファイルでは、マニフェストファイルで指定されたレンダリングエンジンとテンプレート言語で共有リソースを定義します。
これらのファイルが 1 セットになったものを AWS Proton では「環境テンプレート」と呼びます。
説明だけだとピンと来ない、コードを見た方が早いという方はサンプルコードが GitHub に上がっているので参照してみましょう。CloudFormation を読み書きできる方にはシンプルで分かりやすいサンプルになっています。
環境
環境は「環境テンプレート」を元に展開された実際のリソース群です。
「環境テンプレート」は VPC やサブネットのような共有リソースを CloudFormation (と他のいくつかのファイル)で定義したものだと前章で説明しました。そこから展開された環境は、「環境テンプレート」のテンプレートファイルを元に作られた要は CloudFormation スタックです。例えば開発用、ステージング用、本番用の VPC やサブネットです。
AWS Proton でマルチアカウント環境がサポートされたというのは、この環境を作る際にクロスアカウントで「環境」を作れるようになったことを指します。Public Preview 中の AWS Proton では同一アカウント内でしか「環境」を作れませんでした。しかし、GA 後の AWS Proton では「環境」を他の AWS アカウントに作ることが可能となっています。
サービス規模にもよりますが、最近は開発環境と本番環境は別の AWS アカウントで運用しているケースが多いでしょう。より実用的な AWS サービスになったのではないでしょうか。
サービステンプレート
サービステンプレートは、ECS サービスまたは AWS Lambda とそれに付随するインフラと、CI/CD パイプラインを一纏めにしたアプリ/インフラのパーツ群です。
例えば、以下のようなものになります。
- ALB にぶら下がった ECS サービス + CI/CD パイプライン
- API Gateway にぶら下がった Lambda + CI/CD パイプライン
- 常駐して SQS/Kinesis を処理するワーカー ECS サービス + CI/CD パイプライン
実態としては、環境テンプレートと同じようにスキーマファイル、マニフェストファイル、テンプレートファイルで構成されています。
- スキーマファイル
- インスタンステンプレート
- パイプラインテンプレート
「ALB にぶら下がった ECS サービス + CI/CD パイプライン」というサービステンプレートがあるとします。前者の「ALB にぶら下がった ECS サービス」がインスタンステンプレート。後者の「CI/CD パイプライン」がパイプラインテンプレート。スキーマファイルでそれらに環境固有の情報を注入する、といったところでしょうか。
また、互換性のある環境テンプレートを指定できることができます。例えば ECS を利用するのは VPC がないといけないですし、internet-facing な ALB を利用するにはパブリックサブネットが必要です。そういった前提条件を満たしている環境テンプレートを互換性のあるものと定義しておくことで、動作しない環境で、誤ってサービステンプレートが利用されてしまうことを防ぐことができます。
アプリ担当のお仕事
ここまではインフラ担当のお仕事について解説してきました。
AWS Proton を利用する環境において、アプリ担当のお仕事は下記の 3 つです。
- 登録済みの「サービステンプレート」を利用し、アプリのソースコードがあるリポジトリと紐づけます (＝「サービス」)
- CI/CD パイプラインを利用して、サービスにソースコードをデプロイします
- サービスと環境を紐づけてデプロイを行います(＝「サービスインスタンス」)
ここで「サービス」「サービスインスタンス」という 2 つの AWS Proton 用語が出てきました。これらの用語について解説していきます。
サービス
サービスは、「サービステンプレート」に具体的なリポジトリとブランチを紐付けたものです。リポジトリは AWS CodeStar の Connection (接続) という機能を利用して紐付けることができます。AWS CodeStar Connection が対応しているリポジトリサービスは下記の 3 つです。
- GitHub
- GitHub Enteprise Server (GHE)
- BitBucket
な、なんと AWS CodeCommit をサポートしていません。マ、マジですか…。
GitHub でいうと、username/repository の branch とサービスは１：１になります。また、プライベートリポジトリもサポートしているのも嬉しいポイントです。
AWS CodeCommit が利用したいというお客様は、是非担当の SA や営業とコミュニケーションを取ってみてください。
サービスインスタンス
サービスが環境にデプロイされたものをサービスインスタンスと呼びます。つまり、サービス：ブランチ：環境＝１：１：１ということですね。
1 つのサービスに、開発環境と紐付けられたサービスインスタンス、本番と紐付けられたサービスインスタンス、といったように複数のサービスインスタンスを紐づけることができそうなのです。が、サービス作成時にしか出来ないらしく、あとで追加・削除が出来ないので使い勝手が悪そうです。また、サービスとブランチは１：１なので、その点でも使いどころがよく分かりません。
「環境テンプレート」や「サービステンプレート」の説明をした際には説明しなかったのですが、テンプレートはバージョン管理をすることが可能になっています。ですので、あえてサービスとサービスインスタンスを分けて管理しているのだと考えています。
// このあたりは自分もよく分かっていないです…。社内で有識者に聞こう…。
最後に
さて、そろそろ座学は終わりにして AWS Proton をやっていきましょう。
Part.2 ハンズオン編に続く！
Discussion