(レポート) DEV317: AWSの管理系サービスを使ったインフラ管理の自動化とスケール #reinvent
こんにちは、虎塚です。
re:Invent 2016の「DEV317 - Automating and Scaling Infrastructure - Administration with AWS Management Tools」の動画を聴講したのでレポートします。
AWSのChayan Biswasさんと、Cambia Health SolutionsのEric Giffordさん、Brad Davidsonさんが講演されました。
セッションの前半は、CloudFormation, Service Catalog, CloudTrail, CloudWatch, AWS Configで何ができるかの説明とデモンストレーションです。どのサービスで何ができるかよくわからない場合は、ここから見ましょう。セッションの後半は、Cambia Health社で実際にこれらのサービスを組み合わせて、どのようなアーキテクチャでシステムをロギングしているかが紹介されました。
レポート
このセッションで扱うこと
- いくつかの一般的なユースケースのワークスルー
- AWS管理ツールをAWS環境に適用してする方法
- 実際に試せるコード例、デモ、動くサンプル
また、GiffordさんとDavidsonさんが、Cambia Health Solutionsで管理ツールを実際にどのように利用しているかを説明します。開発の俊敏さや生産性を上げて、ボトルネックを取り除きましょう。
主人公の紹介
このセッションに登場する架空の人々と、彼/彼女が本当に必要なもの、気にしていることは、次のとおりです。
- IT管理者のアダム
- インフラを制御したい
- インフラを可視化したい (どのリソースに誰がアクセスしたのか)
- インフラをセキュアに保ちたい
- インフラを定期的に監査したい
- 会社の標準に則ったコンプライアンスを守りたい
- 開発者のデイジー
- リソースやサービスに素早くアクセスしたい (俊敏性)
- ビジネスのために革新的なアプリケーションを開発することにAWSを使いたい
- シンプルに、簡単な方法で使いたい
本セッションでは、アダムとデイジーがAWSの管理ツールを使ってお互いコラボレーションし、二人ともが楽しく仕事をする方法を紹介します。
マネジメントツールのポートフォリオ
本セッションで扱うAWSサービス群は、次のとおりです。
- AWS CoudFormation
- AWS Service Catalog
- AWS CloudTrail
- AWS Config
- Amazon CloudWatch
AWSインフラのライフサイクル全体に、これらのサービスを組み合わせて適用しましょう。
Range of Capability
上で挙げた管理ツールが、capabilityを提供します。
- CloudFormation
- IT管理者がインフラストラクチャをコードで表現できます。インフラを素早く展開できます。
- Service Catalog
- IT管理者が開発者に対してセルフサービスのcapabilityを提供できます
- インフラとプロビジョンと管理をするIT管理者が必要なアクセス権限とパーミッションは、アプリケーションの構築と実行をする開発者に必要なそれとは異なりますが、アクセス権限管理によって実現できます
- CloudTrail, CloudWatch, AWS Config
- インフラがプロビジョンされた後、IT管理者が可視性と制御をメンテナンスします
- IT管理者が定義した部分のインフラだけを開発者が使うことを保証できます
デイジーは開発スタックが必要
典型的なシナリオとして、デイジーは、アプリケーション開発に必要なインフラのスタックを払い出してくれるよう、アダムに依頼します。アダムは、AWS Management Console、AWS CLIやAWS SDKを使って、LAMPスタック (Linux, Apache Http Server, MySQL, PHP) をプロビジョンしました。これはこれでよいでしょう。
しかし、開発者が5人、10人、100人、1000人と増えてきたらどうなるでしょうか。組織が開発者をより多く必要とする時、インフラのスタックをどのように払い出せばいいでしょうか。
AWS CloudFormation
このような場合に、CloudFormationを利用します。CloudFormationの特長を次に示します。
- Infrastructure as Code
- インフラをテンプレート化できる: 1個提供したものを複数提供できる
- バージョンコントロール、レプリカ作成やアップデートができる
- 既存の開発ツールや管理ツールを使える: コードレビュー、アップデート、ツール管理など
- 記述しやすく可読性が高いYAMLで書ける (JSONよりも)
CloudFormationデモ
(動画 08:25-)
CloudFormationコンソールから、アダムがテンプレートを作成してインフラをプロビジョンするデモがおこなわれました。
まず、作成するインフラを図で見せてくれるCloudFormation Designerを紹介しました。アダムはデイジーに大きなインスタンスを作成してほしくないので、CloudFormationテンプレートから非常に大きなインスタンスタイプをあらかじめ削除しました。
次に、ローカルからS3にアップロードしたテンプレートを指定して、スタックの各種属性 (パラメータ) を入力します。アダムがテンプレートで既定の値を設定しておいた属性は、デイジーによって変更できないことが示されます。アダムはデイジーのAWS利用量を把握するため、スタックにコスト追跡用のタグをつけることができます。
俊敏性とセルフサービス性
さて、プロビジョンの速度は解決しました。しかし、デイジーたち開発者はスタックが必要がになるたびにアダムに依頼しなければならない状況は変わっていません。開発者が自分たちでスタックをプロビジョンして、アクセス権限を適切に保つにはどうすればよいでしょうか。
AWS Service Catalog
これを解決するために、アダムがAWS Service Catalogを使います。次の手順によって、IT管理者がプロダクトを定義したポートフォリオを、開発者に提供できます。
- アダムがポートフォリオを作成します
- アダムがテンプレートを記述します
- アダムがプロダクトを作成します
- アダムが制約とアクセス権限 (IAMロール) を追加します
- デイジーがプロダクトをブラウザで確認します
- デイジーが自分でプロダクトをローンチします
- ServiceCatalogがスタックをデプロイします
- ServiceCatalogが開発者にスタック作成完了を通知します
ServiceCatalogの特長を次に示します。
- セルフサービス
- 許可されたリソースとアーキテクチャを定義できる
- プロビジョンとアクセスのパーミッションを分離できる
- プロジェクトや組織の部署ごとに利用を制御できる
- スタック作成時にリソースにタグ付けを強制できる
- アダムが指定したタグをデイジーは変更できない
ServiceCatalogのデモ
(動画 13:20-)
まず、アダムがIT管理者アカウントでManagement Consoleにログインします。ServiceCatalogコンソールで空のポートフォリオを作成し、プロダクトを追加します。スタックが上手く動かなかった時のために、サポート情報として管理者の連絡先を設定できます。ローカルにあるCloudFormationテンプレートをここで指定します。将来、今回のテンプレートと異なるインスタンスタイプを追加したくなった場合は、バージョン2のテンプレートを指定できます。これで1つのプロダクトを含むポートフォリオができました。
次に、プロダクトに制約を追加します。今回はローンチの制約として、デイジーでなくServiceCatalogがプロダクトをプロビジョンできるように、IAMロールを指定します。さらに、デイジーが開発者向けポートフォリオにアクセスできるように、IAMロールを指定します。
それから、デイジーが開発者アカウントでManagement Consoleにログインします。アダムが作ったプロダクトを選択して、ローンチします。プロダクトが複数バージョンある場合は、好きなバージョンを選択できます。ローンチする前に、DBのユーザーパスワードやIPアドレスなど追加の情報をスタックに指定します。
可視化と監査
管理者がService Catalogに定義したプロダクトを開発者がローンチしたことで、プロビジョンが実行されました。構成の可視化やチェックには、CloudTrail、Config、CloudWatchなどを使います。
AWS CloudTrail
CloudTrailは、APIコールのロギングをおこないます。
CloudTailで、デイジーが利用したAPIのログをS3に保存できます。また、CloudWatchに送信することで、ログの中身の監視やアラートを設定できます。
AWS Config
AWS環境に発生した変更を記録するには、WS Configを使います。AWS Configの特徴を次に示します。
- 継続的な監視とリソースに対する設定変更の記録をおこなう
- アカウント内のAWSリソースのインベントリ
- 新規作成されたリソースや、削除されたリソースも対象にする
- 設定の変更を検知して、コンプライアンスを守るために通知する
- 可視性を高め、変化を検知してアクションを起こす
もう少し詳しくみてみましょう。
- Config Ruleを使って、ポリシーやガイドラインを定義する
- 環境の変更が検知されると、ConfigはそれをConfig Ruleと照らして評価する
- AWSがpre-builtのConfig Ruleを提供しているので、ゼロからルールを書く必要はなく、ただ選べばよい
- AWS Lambdaを使ってカスタムルールを作成することもできる
- ダッシュボードで、環境のコンプライアンス準拠状況や、変更の詳細を確認できる
- Githubリポジトリに、コミュニティが提供するさまざまなRuleのコードがある
CloudTrailとAWS Configのデモ
(動画 20:38-)
このデモでは、環境を監査するために、アダムがCloudTrailとConfigを設定済みであるものとします。
CloudTrailコンソールのAPIアクティビティ履歴では、ユーザを指定して、API操作の履歴を追うことができます。ここでデイジーを指定したところ、デイジーがセキュリティグループにインバウンドのルールを追加した記録が見つかりました。
履歴詳細の［Config timeline］リンクをクリックすると、AWS Configのタイムライン画面へ遷移し、どのような変更をしたか詳細を確認できます。今回の場合は、セキュリティグループの変更前と変更後のルールを見ることができます。変更前には特定のIPアドレスからのインバウンド通信だけを許可していましたが、変更後にはすべてのIPアドレスからアクセス可能に設定されていました。
Configの画面ではさらに、そのセキュリティグループがどのEC2インスタンスに紐付いているかが表示されます。つまり、どのインスタンスに脆弱性があるかを確認できます。
制御と自動修正
セキュリティグループに脆弱性のある変更が加えられた際に、アダムがリアルタイムで監視していなくても、自動で修復されるようにするにはどうすればよいでしょうか。ここでもAWS Configを使います。
手動で設定を修正するデモ
(動画 22:38-)
AWS Configコンソールを表示します。pre-builtのConfig Ruleとして、「/0」で終わるルールの追加を制限するルールが提供されているので、選択します。
Config Ruleで定義したコンプライアンスに適合しないセキュリティグループが、一覧で表示されます。先ほどデイジーがルールを追加されたセキュリティグループも含まれています。IT管理者はそれを手動で削除できます。
自動で設定を修正するデモ
(動画 23:39-)
まず、AWS Configがコンプライアンス違反の設定を検知した時に通知するSNSトピックを確認します。SNSのsubscriptionとして、Lambda関数を設定します。
次に、セキュリティグループを意図した状態に保持するコードを、Lambda関数に書きます。LambdaがAWSComplianceChangeNotificationを受け取り、「/0」で終わるIPアドレスを含むルールをAWS Configが検知したことを確認したら、同じLambda関数内に定義した別の関数を呼び出します。この関数は、当該ルールをセキュリティグループから削除します。（サンプルコードは、動画でご覧ください）
Amazon CloudWatch
これでコンプライアンス違反の設定を検知し、自動修復できるようになりました。しかし、自分がインフラに対しておこなった設定が消えていたら、デイジーは驚くことでしょう。
CloudWatchを使ってログを集めると、インフラの設定が変更された時に、アダムにもデイジーにも通知できます。CloudWatchの構成要素を次に示します。
- ログ
- EC2インスタンスからのログを監視、保管する
- メトリックス
- 対象リソースの統計
- アラーム
- 閾値に達した時にアクションをおこなう
- イベント
- イベントストリームに反応する
CloudWatch Eventのデモ
(動画 26:55-)
もし開発者がConfigによる記録を止めたら、自動的に記録を再開させたいとします。それには、CloudWatch EventのコンソールでEvent Ruleを作成します。
まず、イベント種別から「AWS API call」を選び、AWSサービスから「Config」を選びます。特定の操作として「StopConfigurationRecorder」をさらに選びます。これで、Configによる記録が停止されたことを検知できます。
次に、ターゲットを設定します。今回は、Lambda関数を指定します。このLambdaは、デイジーが呼び出し権限を持っている必要があります。Lambda関数のコードには、StartConfigurationRecorderを呼び出す記述をします。
最後に、ルールの名前と詳細を設定します。「Configがもしstopされたらrestartする」旨を記述します。
これで、デイジーがConfigから抜け出すことはできなくなりました。
Cambia Health Solutionsでの事例
Cambia Healthは、100年近く前に設立されたUSの企業です。より個人にフォーカスされるようになったヘルスケアを、持続可能な経済によって実現できるように取り組んでいます。Cambia Healthは、マイクロサービスベースで構築したデータ分析システムを、AWS上で運用しています。
クラウドセキュリティと自動化原則
Cambia Healthでは、次のような考えでAWSを利用しています。
- HIPAAのコンプライアンスに準拠して、データの安全な保存には非常に配慮する必要がある
- AWSをよりセキュアに使うためにDevOpsの方法論を採用する: 自動化によって偏りやリスクを減らす
- サーバーレスとマネージドサービスの活用によって、共有責任モデルをレバレッジする (パッチを当てるような対応に終始しない)
- gateではなくguardrailを作る: ビジネスの速度を落とさない
- 継続的な監視を実現する
初期のシステムアーキテクチャ
最初のシステムアーキテクチャは、次のようなものでした。
- すべてのAWSアカウントにCloudTrailを導入して、S3バケットにログを集積する
- S3がログファイルを受けとるとSNSにイベントを通知する
- S3イベント通知でログイベントを検査するLambdaが起動される
- 新しいS3ログファイルを受け取る
- イベントをElasticsearch、Logstash、Kibanaなどに保管し、レポート作成する
- LambdaがSNSにアラート通知を送信する
Lambdaで次のような項目を監視しています。
- MFAの無効
- 認可されていないリージョンの利用
- CloudTrailの無効
- VPCフローログの無効
このアーキテクチャには、次の長所があります。
- シンプル
- 独立したLambda関数で実装できる
一方、次の短所があります。
- Lambda関数ごとにポリシーなどのカスタマイズが必要
- CloudTrailイベントには (たとえば、どの部署の誰が何のためにAPI操作をしたか、といった) コンテキストが欠如している
新しいシステムアーキテクチャ
上に挙げた短所を解決するために、Cambia Healthはシステムアーキテクチャを3層Lambda構造に変更しました。
より効率的にするとともに、リアルタイムにアクションが取れるようにログにコンテキストを追加し、CI/CDパイプラインと結合できるように柔軟性を確保しました。
- すべてのAWSアカウントにCloudTrailを導入して、S3バケットにログを集積する
- S3がログファイルを受けとるとSNSにイベントを通知する
- S3イベント通知を受けたLambdaが、ログファイルを展開し、Cloud Watch Eventにイベントを送る
- 新しいS3ログファイルを受け取る
- イベントをトリアージするLambdaが起動する
- Lambdaが、Event Dataの詳細 (組織情報など) をDynamoDBテーブルに書き込む
- Lambdaが、シグネチャを別のDynamoDBテーブルに書き込む
- Lambdaが、イベントをElasticsearch、Logstash、Kibanaなどに保管したり、アラートを上げたりする
- Lambdaが、アクションのためのLambdaチェーンをさらに起動する
これで十分でしょうか。新しいアーキテクチャの長所は、次のとおりです。
- より適した粒度のイベントデータを豊富に集められる
- ポリシー/シグネチャを各Lambdaではなくデータベースに一元化できる
- AWS Lambdaの速度を最適化できる
一方、短所は次のとおりです。
- 使うのもメンテナンスするのも複雑になった
- 回帰テストが必要になった
次に必要なもの
Cambia Health社では、現在さらに次のような環境を目指しています。
- ポリシーを管理するためのUIやレポートを見るためのダッシュボード
- プロダクション環境のログで安全にテストするためのdry runモード
- DBを最新の状態に保つこと
- チケットシステムとの連携
- リソースの作成時にセキュアな設定を適用すること
- VPCフローログからセキュリティ上の脅威を検知する技術
デモ
(動画 35:22-)
Davidsonさんに交代して、13分間のデモンストレーションがおこなわれました。ぜひ動画をご覧ください。
おわりに
CloudFormation, Service Catalog, CloudTrail, CloudWatch, Configといった管理系サービスのデモをひととおり見ることができるセッションでした。組織のポリシーに合ったAWS環境の管理方法や、AWSサービスの使い道を考える上で、役に立つと思います。
ちょっと気になったところとして、CloudWatch Eventのデモでは、デイジーのIAMポリシーでConfigのStopを明示的に拒否したほうがよいのではないかと思いました。皆さんはどう思いますか？
Cambia Health社のAWS環境の紹介も、具体的で興味深いものでした。AWS環境の管理方法を設計する上で、いろいろ参考にできそうです。
それでは、また。
