【レポート】「クラウド運用管理の最前線 ～日米の最新状況から～」AWS Summit Tokyo 2019 #AWSSummit
AWS Summit Tokyo 2019のセッションレポートです。こちらでは「クラウド運用管理の最前線 ～日米の最新状況から～」の内容をレポートします。
こんにちは、臼田です。
こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。
本ブログでは『クラウド運用管理の最前線 ～日米の最新状況から～』に関する内容をレポートしたいと思います。
セッション概要
当セッションの登壇者及び概要は以下の通りです。
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
大村 幸敬
Amazon Web Services, Inc. Partner Solutions Architect
酒徳 知明
クラウドの活用が先行している米国では、管理対象のシステム規模の拡大に伴い、効率の向上によってスケーラブルな運用を実現することが求められています。このセッションでは米国のパートナーを担当するソリューションアーキテクトと共に、日米のクラウド運用管理の最新状況を解説します。その上で、スケーラブルな運用に求められる、効率化、ガバナンス、コスト最適化を実現するための具体的な手法を紹介します。
レポート
- 日本の企業からの相談例
- 事業部門
- デジタルトランスファー施策
- 情報システム部
- システム移行
- ガバナンスとセキュリティの確保、閉域網による接続
- クラウドの理解、エンジニアの育成
- 事業部門
- クラウド活用のフェーズ
- 日本ではこれからよりクラウドを活用するフェーズ
- 米国ではもっと進んでいる
- 今日持ち帰るポイント
- 日本から: くらう堂任用体制のベストプラクティス
- 米国から: 大規模な環境におけるスケーラブルな運用プラクティス
- よりコントロール・ガバナンスを効かせる
- コスト最適化
- 対象者
- ITシステムの運用を改善したい全てのエンジニア
- マネジメントコンソールは誰のものか
- 皆さんの組織ではどうでしょうか？
- インフラ？アプリ？外部の担当者？
- 皆さんの組織ではどうでしょうか？
- AWSはITのツールボックス
- 単にサーバを用意するだけのものではない
- EC2ベースの構成
- インフラチームがEC2やS3などを用意
- アプリチームがOS異常を見る
- これだとマネジメントコンソールはインフラチームが触る
- サーバレス構成
- マネジメントコンソールはLambdaやRDSなどミドルウェアレベルまで面倒を見ることになる
- インフラチームがここまで見れるでしょうか？
- 運用はおそらく回らない
- マネージドサービスを活用する場合にはアプリチームもインフラチームもマネジメントコンソールを触る
- マネジメントコンソールはみんなのもの
- 従来の仮想サーバの管理ツールと同じ役割分断は非効率
- クラウドを活かす運用体制
- ITシステム開発の体制とスケジュール
- オンプレミスではアプリ・インフラ・運用で分かれる
- ウォーターフォールでのアプリ開発
- インフラでは要件定義して調達
- クラウドでもアプリは変わらない
- インフラでは実機検証や環境のコピー、自動化もできる
- しかし、インフラとアプリのコミュニケーションコストが大きくて非効率
- セキュリティグループの変更とかエクセルで申請したりしますか？
- 本当はアプリとインフラは同じチームでやったほうがいい
- コミュニケーションを密にやる
- ガバナンス・コンプライアンスはクラウド共通運用を策定する
- アカウントをまるごと払い出す
- 基本設定のテンプレート化
- アカウントを監視
- 既存の運用監視も活用
- ツールを使って自動化
- 共通運用のチームではロギングややってはいけないことを徹底していくことによりみんなやりやすくなる
- ITシステム開発の体制とスケジュール
- AWSマルチアカウント戦略
- AWSアカウントが提供するもの
- 請求の分離
- セキュリティ及びリソースの教会
- APIの制限及びスロットリング
- システムごとにアカウントを分けるといい
- マルチアカウント管理のゴール
- 監査可能
- スケーラブル
- フレキシブル
- 自動化
- ブロッカーではなくガードレール
- セルフサービス
- マルチアカウントベストプラクティス
- 共通運用チームが行うこと
- 下記アカウントを作成
- 請求アカウント
- 請求
- アカウント払い出し
- 共有サービスアカウント
- AD等
- セキュリティ&監査アカウント
- ログの集約
- 監査の実施
- アプリ&インフラチーム
- アプリケーションのアカウントが払い出される
- 共通運用チームのアカウントと連携する
- アカウントが増えてもスケーラブルに対応できる
- 共通運用チームが行うこと
- アプリ/チーム特性によるパターン化の例
- DevOpsチーム
- 個別運用まで見るように
- アプリインフラの分担
- AWSリソースからインフラチームで見る
- 研究開発
- 全てのAWSリソースを活用する
- デジタルサンドボックス
- ただしセキュリティなどについて理解してもらっている前提
- DevOpsチーム
- AWSアカウントが提供するもの
- クラウドを活用する体制のポイント
- マネジメントコンソールはみんなのもの
- クラウドのスピードを活かすための体制
- マルチアカウント管理のベストプラクティス
- ここから米国の話
- 上記の体制が出来ているお客様での課題などの話
- 日本よりも圧倒的に規模感が大きい
- 大規模クラウド運用におけるポイント
- コントロール
- 大規模環境では特に重要
- 権限がない場合、利用したいサービスにアクセスできない
- セキュリティ的には間違っていない
- しかしデベロッパーが新しいサービスを試すことが出来ない
- 一般的にはトレードオフになる
- AWSではガードレールを提唱している
- AWSの操作はAPIで行われ、すぐに検知できる
- ベースは最低限を絞っていて、やってはいけないことだけ監視して絞っていく
- 大規模だとプロアクティブにやっていっても限度がある
- ゲートでの確認もあるが、その手前でチェックする手法も併用する
- 具体的にはCloudFormationを活用する
- インフラストラクチャをコードで管理
- サーバレスも管理できる
- マルチアカウント、マルチリージョン対応
- テンプレート検証はcfn-lint
- 書かれたコードの中のセキュリティリスクも教えてくれる
- 例ではパブリックなルーティングテーブルをプライベートにも当てていることを検知
- cfn-nag
- セキュリティグループがオープンであることに気づける
- ポイント
- いかに事前にセキュリティリスクに気づけるようにするかが大事
- 意図的にコントロール・ガバナンスを効かせる仕組みづくりをする
- コスト最適化
- リフト&シフトか最適化かクラウドネイティブか
- 徐々にコストは抑えられる
- リフト&シフト最適化のポイント
- ライトサイジング
- 伸縮性向上
- RI/Spot最適化
- AWS Trusted Advisorでコスト最適化
- EC2 Right Sizing
- 直近2週間のEC2のStutsをみてサイジングの推奨事項を提供
- レコメンデーションをどうするか
- サードパーティを紹介
- CloudCheckr
- cloudinary
- などなど
- ポイント
- レコメンデーションをどう活用するかが重要
- ツールを使った自前運用でもいいが、より楽になるならサードパーティの活用も検討
- 次世代のクラウドマネジメント
- Machine Learning Enabled
- MLを有効活用していく
- キャパシティプランニング
- 異常検知
- ノイズキャンセリング
- 見る部分を減らす
- 障害に備えるメカニズム
- Resiliencyを求める事が最近多くなった
- 回復力
- Design for Failure
- Error Ingestion
- 意図的に障害を起こす
- Auroraに障害を起こす
- Resiliencyを求める事が最近多くなった
- Chaos Engineering
- 意図的に障害を起こす
- Netflixが本番環境でやっている
- 実際のお客様では検証環境での実施が多い
- Machine Learning Enabled
- コントロール
感想
環境が増えてくると、いかにマルチアカウントの管理を行っていくかが大切です。
ガードレールとして環境を提供してマルチアカウントの管理ができると素晴らしいと思います。
米国の状況も参考に、より大規模に対応していくためにどうしていくかを考えていきたいですね。
![[アップデート] AWS Database Migration Service (AWS DMS) の変換ルールでデータマスキング機能が使えるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-2456484469e6d1d994b324e579746890/9e41fb473821c8323d8ec33477b8d8a9/aws-dms)
