[セッションレポート] AWSにおける運用管理の最新ベストプラクティス #AWSInnovate

こんにちは　園部です。

4月8日-5月7日に開催されていました AWS Innovate のセッションレポートとなります。

なぜ、このタイミング？！ という疑問をいただかれる方もいると思いますが
（ちょっとした機運を感じ...）とても良い内容のため、やっぱりブログにしたいと思い立ったためです。

AWS Innovate については、弊社のメンバーが取り上げている記事にて紹介されています。

• 【AWS公式】AWS Innovateを受けて感じた3つのメリット
• AWS資格勉強を始めようと思っている方！今がチャンスですよー 〜AWS Innovate試験対策セッションのご紹介〜

本記事は、こちらのセッション一覧 にあります
「AWSにおける運用管理の最新ベストプラクティス」のセッションレポートとなります。

セッション概要

クラウドにシステムを構築しました。さて、その運用はどのように行いますか？

AWS上のシステムはオンプレミスと同様の方法で運用することもできますが、運用のための多様なサービス群（Management Tools）やAPIによる自動化を活用することで、組織に合わせた運用をより効率よく実現することができます。

このセッションではクラウド運用の原理原則とAWS運用における最新ベストプラクティスをご紹介します

（引用：公式サイトAWS Innovate より）

スピーカー＆資料

スピーカー

大村 幸敬 さん

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 インダストリソリューション部
ソリューションアーキテクト

資料

AWS Innovate 特設サイトから動画およびPDFをダウンロードすることが可能ですが、事前に期間内に申し込み登録が必要です。
(今回、記事にする辺りに事前にスライド利用の許可をいただいております)

レポート

AWS 運用の原則（Well-Architected）

Well-Architected（以降 W-A） フレームワークの1つである 「運用の優秀性」 について取り上げられています。

5つの柱

（引用：上記セッション資料 より）

運用の優秀性：　
ビジネス価値をもたらし、サポートプロセスと手順の継続的な向上を実現するために、システムを実行およびモニタリングする能力。

（引用：W-A ホワイトペーパーより）

こちらの「運用の優秀性」については、現場エンジニアのみではなくビジネスサイドの要求を含めて運用改善を行う ことが重要となります。

運用の原則（６か条）

1. コードを使って運用する
2. 注記付きドキュメントを自動生成する
3. 頻繁に、小さく、可逆的に変更する
4. 運用手順を頻繁に見直す
5. 危険の事前予測と排除を行う
6. 全ての運用の失敗から学ぶ

3つのエリア（準備・運用・改善）

各エリア（フェーズ）におけるタスクと求められる内容（ポイント）がW-Aでは定義されています。

（引用：上記セッション資料 より）

こちらの図は、後ほど 「運用パターン別サービスの使い分け」 でも再登場します。

所感

「運用の優秀性」について詳細が気になる方は、ホワイトペーパーと合わせて、こちらもご覧ください。

• Well-Architected Frameworkの柱「運用の優位性」を読み解いてみた

その他にもW-Aシリーズの解説がありますので、こちらもぜひ！

• Well-Architected Frameworkの柱「セキュリティ」を読み解いてみた
• Well-Architected Frameworkの柱「信頼性」を読み解いてみた
• Well-Architected Frameworkの柱「パフォーマンス効率」を読み解いてみた

上記、赤字で記載させていただいた 「現場エンジニアのみではなくビジネスサイドの要求を含めて運用改善を行う」 は非常に重要な要素だと思います。

良いサービスを提供するための手段として行う運用が、運用を行うこと自体が目的となっている状況下では良い運用・改善は難しいのではないでしょうか。そのため、普段からサービスの価値・目的を意識することや、運用内に取り込むことが重要ではないかと思います。
また、より良いサービスを目指すのであれば、ビジネスサイド側にも運用の現状や重要性を知っていただく必要もあると思います。双方の理解があったこそ効果的な取り組みが行えるのではないでしょうか。

クラウドを活かす運用体制

続いて「AWS（クラウド）へ移行したが、いざ運用開始すると窮屈で十分に活用できない」という課題について体制面から解説されています。

ケース１： システム・体制ともにリフトのみ

オンプレミスでシステムを構成するコンポーネントに対応するAWSサービスへ置き換える移行（AWSへリフト）した際に、運用体制もオンプレミス時代のままとなっている。

アプリレイヤーはアプリケーションチーム、アプリレイヤー以外はインフラチームといった分業された体制です。 その場合、AWS マネジメントコンソールによるリソース（VPC、EC2、セキュリティグループ）作成はインフラチームが担当することになります。 この状態ではクラウドのメリットを活かしたアーキテクチャ・体制とは言えません。

ケース２: マネージドサービスを利用

次にAWSが提供するマネージドサービス（RDSなど）を活用すると責任分担が変化します。

（引用：上記セッション資料 より）

前回の体制を踏襲している場合、リソース作成はインフラチームが担当することとなりますが
作成されたDBの監視や性能管理は、どのチームが行うのか？という課題が発生します。

AWS ではそれらをサポートするサービスを提供していますが、もしアプリケーションチームがマネジメントコンソールなどを利用出来ない場合は、インフラチームに確認してもらうなどが必要となり効率や権限分離が上手くいっていない状態となります。

ケース3: サーバーレスアーキテクチャを利用

アプリケーションの実行環境はAWSが管理する環境となり、デプロイ、ログ、設定変更などを行う場合でもインフラチームへの依頼が必要となってしまいます。 これでは運用が回らないため、アプリケーションチームもAWSリソースを主体的に利用・操作する必要性が出てきます。

ケース4: 開発時の体制

オンプレミス環境では、ハードウェア調達などから時間をかけて準備・構築していたものが、クラウドを利用することで調達が短くなり、設計をするため実際に動かしながら詳細な設計を行うことが可能となります。これはクラウド利用のメリットの一つとなります。

ただし今までの体制のままでは、アプリ開発チームから設定変更をインフラ構築チームに依頼して対応するフローのままとなってしまい、せっかくのクラウドを利用することで得たスピードメリットが活かせない状況となってしまいます。

クラウドを活用する開発体制の例

• アプリ開発とインフラ構築を同じチームとする
• アプリ開発メンバーでインフラ構築まで行う

各チームに権限委譲することでのリスクが懸念されるため、共通基盤チームとしてガバナンスを運用チームが担当する。

マルチアカウント

先ほどの体制を実現するために、4つの機能を持つアカウントを作成することを推奨しています。

1. 請求
2. セキュリティ＆監査
3. 共有サービス
4. アプリケーション

• 払い出す先のチームレベルによって、権限や提供する状態を分けて提供する。

所感

私自身もケース2 の状態でマネージドも利用するが分業制による非効率の中、増え続けるアカウントに四苦八苦していた記憶があります。会社やサービス数などによって、例のような体制がフィットしないかもしれませんが、ヒントとなる要素があるのではないでしょうか。

クラウド運用チームは、技術調査や新しいチームへのAWSスキル習得サポートなども行えるのではないでしょうか。CCoEの役割と重なる部分もあるかと個人的には思います。

運用パターン別サービスの使い分け

もう一度、具体的な運用内容に戻り、W-A の各エリア・タスクにおける各パターン例を紹介されています。

① AWS環境の操作 - インタラクティブ

イレギュラーな操作が必要とされた場合

[やりたいこと]

• 手動でAWS API を実行したい

[実現方法]

• AWS CLI で呼び出す
• マネジメントコンソールで呼び出す

① AWS環境の操作 - 自動

定型的な作業などを自動化したい場合

[やりたいこと]

• 自動でAWS API を実行したい

[実現方法]

• シェルスクリプトで AWS CLI で呼び出す
• lambda で AWS API を呼び出す（CloudWatch Eventでスケジュール実行も可能）

② サーバの操作 - ログインせずインタラクティブ操作

[やりたいこと]

• サーバにログインせずインタラクティブに操作したい
• サーバでの操作ログを記録したい

[実現方法]

• SSM Session Manager を使用して対象サーバのシェルにアクセス
• 操作ログはS3に保存

② サーバの操作 - ログインせず定型処理

[やりたいこと]

• サーバに決まったコマンド操作を実行したい

[実現方法]

• 事前定義済みの SSM RunCommand ドキュメントをサーバ群を指定して実行

③ ジョブ管理 - 定期処理（APIの実行）

[やりたいこと]

• 定期的に何かやりたい

[実現方法]

• CloudWatch Events から lambda を呼び出す（CloudWatch Eventsはマネージドサービスなため可用性などの考慮は不要）

③ ジョブ管理 - 既存環境と連携したスケジュールの実行

[やりたいこと]

• 既存のジョブ管理ツールでAWS上のサーバを管理したい

[実現方法]

• EC2にジョブ管理ツールのエージェントを導入して直接管理
• ジョブ管理マネージャ自身にAWS CLIを導入しRunCommand経由でサーバ上のコマンドを実行

④ 監視・ログ管理

[やりたいこと]

• AWSサービスのメトリクス・ログ収集
• OS上のメトリクス・ログ収集
• 異常時に通知や対応を行う

[実現方法]

• AWS サービスのメトリクスはCloudWatch で収集
• AWS サービスのログ、OS上のログはCloudWatch Logs で収集(保存期間指定)
• 詳しいログの分析を CloudWatch Logs Insight で実施
• 異常検出時は lambda で通知あるいは自動対応を行う

⑤ バックアップ・リカバリ

[やりたいこと]

• バックアップを自動的ないし手動で取得したい
• リカバリしたい

[実現方法]

• 設定済みEC2からAMI（起動イメージ）を作成する
• RDS のスナップショットや自動バックアップからリカバリ（新しいRDSの作成）を行う

⑥ 変更管理・監査

[やりたいこと]

• AWS の設定変更や、サーバ上のソフトウェア導入情報を継続的に収集して分析したい
• 過去の変更記録を追跡したりコンプライアンス違反の場合に自動的に通知および対応したい

[実現方法]

• AWS Config を有効化する（特定リソースに対する変更者・変更履歴が確認できる）
• SSM でインベントリの収集を有効化する（管理対象サーバ（オンプレ含め）OS上の構成情報を記録）
• マネジメントコンソールで構成情報に対してクエリを実行
• AWS Config Rules でルール逸脱時の自動対応を設定
• CloudWatch Events で定期的に lambda を実行し記録に対するチェックを行う

⑦ 構成管理 - AWS環境

[やりたいこと]

• AWS環境設定のコード化
• 環境の構築・変更・削除の自動化

[実現方法]

• CloudFormation テンプレートで構成を記述し（YAMLなど）スタックを作成する

⑧ 構成管理 - CI/CD パイプライン

[やりたいこと]

• アプリケーションの開発パイプライン（ビルド・テスト・デプロイの流れ）の迅速化と標準化

[実現方法]

• AWSのCodeシリーズを使ってアプリとインフラのパイプラインを構成する

さいごに

今回のセッションで紹介された体制例やW-Aを取り入れながら、運用も開発、そしてビジネスサイドにとっても効果的な（楽しい）管理・体制を増やしていきたいですね。

また Well-Architected Framework については、弊社でもホットなテーマでもあります。 気になる点やご相談などがございましたら、お気軽にお問い合わせください。

• AWS Well-Architected Framework レビューの進め方について
• 無料のAWS Well-Architected Toolでクラウド最適化への一歩を踏み出そう
• AWSの運用ベストプラクティス 「運用上の優秀性」についての解釈