[レポート]AWS のオペレーション最適化の勘所 #AWSSummit

今日は2018/05/30より3日間に渡って東京で開催されている「AWS Summit Tokyo 2018」からセッションをレポートします。 このレポートはTech中級 「AWS のオペレーション最適化の勘所」です。スピーカーはアマゾンウェブサービスジャパン株式会社 テクニカルアカウントマネージャの伊藤 裕史氏です。

レポート

オペレーションの最適化の要素

• ベストプラクティスに基づく準備
• 積雪なモニタリング
• 適切な運用
• 継続的な見直し

Well-Architected Framework

クラウドアーキテクチャ設計・運用の考え方とベストプラクティス。 運用上の優秀性についての項目は、実現のための大原則と確認のための質問で構成される。

原則1: Operation as codeの実践

AWSはいろんなサービスをAPIで操作できる。 ConfigやCloudWatchをトリガーに、LambdaやAuto Scalingで自動で対応する。 これによりヒューマンエラーを防止できる。

原則2: 注釈でドキュメンテーションする

アプリケーションと同じで運用手順書もアップデートしていく。 ドキュメントの更新をデプロイプロセスに組み込む。

原則3: 頻繁に、小さく、可逆な変更を加える

原則4: 頻繁に運用手順を見直す

定期的にGameDayを実施して、オペレーション手順をレビューする。 GameDay=実際に問題を起こしてみて、効果の確認、効率化できるポイントを探す。

原則5: 障害を予測する

机上演習を実施する。 "Pre-mortem"を実施して、障害シナリオとそのインパクトを理解する。 対応手順が効果的であることを確認する。

原則6: イベントと障害対応から学ぶ

うまく言った対応も失敗した対応も振り返る。 ログを集めて、可視化し分析する。

確認のための質問

• 運用における優先度を決める要因は何ですか？
• どのようにアプリケーション運用性をデザインしますか？
• 運用をどのように進化させますか？

実際のお客様環境によくある課題

タグを管理・活用していますか？

コスト配分のタグを決めているが、つけ忘れが多い。

AWS Service Catalog、CloudFormationなどデプロイ時に強制させる。 IAMポリシーで絞るなどの対策がある。 実際にここまですぐにできることは少ないので、チェックする対策を採れる。

AWS Configで必須タグが付いているかをチェックできる。 事前定義済みのルール「required-tags」を利用できる。 必須タグが付いていないリソースについては、"非準拠"と表示される。

タグを使ったリソースグループ管理

タグをキーにしてAWS Systems Managerを使ってリソースグループ化して管理。 グループ化したリソースに対して一括処理も可能。 タグでリソースをフィルタ表示したり、AWS Systems ManagerのAutoMationでグループ単位で処理ができる。

タグで頑張りすぎないことも大事

タグをサポートしていない費目、リソースもある。 適切な単位でアカウントを分割することも検討して欲しい。 タグの設計指針は、AWS Answersで紹介されている。

メンテナンスなどの通知はきちんと受け取れていますか？

通知の受け取りにおけるよくある課題

特定の担当者にしか通知がいかない。 AWS Personal Health Dashboardで解決できる。 アカウント固有のリソースに対するメンテナンス情報や影響を受ける可能性のあるAWSの大規模障害の情報を提供している。

チャット連携や、障害管理ツールへの連携が可能。 Githubのaws-health-toolsで、チャット連携などのサンプルを提供している。

代替の連絡先の活用

アカウントの設定情報に代替の連絡先を設定可能。 補助的に利用して欲しい。

複数のアカウントをまとめて管理できていますか？

複数アカウント管理の課題

• 部門ごとやアプリケーションごとにアカウントを作っているのだけど、ガバナンスを効かせられない
• 請求の統合を行なっているが、各アカウントの利用状況を把握できない
• 請求統合でRIが共有されてしまう

AWS Organizationによる請求統合

複数のAWSアカウントに対する請求を1つのMasterアカウントにまとめて一括請求する仕組みを作れる。

一括請求以外の機能もある。 複数のAWSアカウントに適用するポリシーを集中管理できる。 AWSのサービスへのアクセス制御。 AWSアカウントの作成と管理の自動化。 アクセス制御は既存のアカウントには適用しづらいことが多いが、新規アカウントについては検討して欲しい。

AWS Organizationは、AWS Config、Firewall Manager、Single Sign-Onと連携可能。

Cost Explorer API

Cost ExplorerはGUIでの利用が基本で、CSVで出力できるレベルだった。 APIが出たことによって、いろんなライブラリと組み合わせて自分が出したいように出せるようになった。 Githubのaws-cost-explorer-reportでサンプルを提供している。 APIは課金の対象になるので、注意して欲しい。

Reserved Instanceの共有拒否設定

諸事情でReserved Instanceの共有をしたくない場合、設定できるようになった。 予算管理上、共有したくない場合は活用して欲しい。

AWSサポートは活用できていますか？

AWSサポート活用における課題

• 複数のアカウント間でナレッジが共有されず、なんども同じことを聞いてしまっている
• 社内で使っている課題管理システムと連携したい
• サポートの調査が思うように進まない

AWSサポート APIを利用可能。 サポート問い合わせの自動化や課題管理ツールとの連携が可能。 Operation as Codeで"聞く"という操作も自動化できる。 フル参照を行うには、ビジネス以上のサポートである必要がある。

サポートお問い合わせのベストプラクティス

• 1つのお問い合わせで関連性のない複数の質問をしない
• 問い合わせ対象リソースの所有者が起票していることを確認する
• 適切な緊急度を設定
• 問い合わせの際に以下を添付する
  • 事象の発生時間
  • リソースの詳細（リージョン、リソースID、名前）
  • 発生した事象の詳細
  • SDKヤCLIであれば、エラー出力
  • ネットワーク疎通であれば、通信元と通信先のリソース情報

AWS Trusted Advisor

AWSベストプラクティスに従いチェックする。 コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービス制限の観点でチェックする。 セキュリティについては、特にチェックして欲しい。

Trusted AdvisorとCloudWatchを連携できる。 具体的には、使用率の低いインスタンスが発生 ＞ Lambdaで自動対処や、人に通知できる。 AWS Limit MonistorをAWS Answersで提供しているので確認して欲しい。

まとめ

あるべきオペレーション環境の指針としてのWell-Architected Frameworkを活用して欲しい。 セッションが多くのお客様と直面する課題とその対応のヒントになれば嬉しい。

おわりに

今回のSummitでは、Well-Architected Frameworkがよく聞きます。本セッションでも取り上げられました。 また、オペレーションに役立つ情報が数多くGithubやAWS Answersで提供されていることがわかりました。