DevIO2024_レガシー運用からの脱却 -クラウド活用の実践事例とベストプラクティス-

プラットフォームエンジニアリングを1年半実践し、格闘した記録です。プラットフォームエンジニアリングが出てきた背景や、CCoEとSREの違いを整理しました。また、開発チームの認知的負荷をどう下げていくか、システムを横串で全体最適を試行錯誤しながら導入した内容をまとめました。プラットフォームチームの道は続く。

Transcript

1. レガシー運⽤からの脱却 “クラウド活⽤の実践事例とベストプラクティス” 2024.7.18 AWS事業本部 千葉 淳
2. Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い
3. ⾃⼰紹介 コンニチハ、千葉です。クラウド運⽤と効率化に 情熱を持ち、企業のデジタル変⾰をサポートして います。AWS歴10年以上。本⽇はよろしくお願い します！ 3 DevelopersIO のアイコン →
4. セッション概要 クラウドのメリットを⼗分に活⽤したい⽅へ！ このセッションでは、プラットフォームエンジニアリ ングという考え⽅を2023年から1年半、実践し試⾏錯 誤した結果、⾒えてきた⽣きたナレッジを共有しま す。プラットフォームチームの必要性を考え、レガ シー運⽤からの脱却を⽬指した実話です。 4
5. アジェンダ 1. クラウド運⽤の現状と課題 2. プラットフォームチーム -⽴ち上げ編- 3. プラットフォームチーム -実践編- 4. まとめ 5
6. クラウド運⽤の現状と課題 6
7. お客様から⾔われた⼀⾔ いろいろなベンダーがいるけど、ほとんどの ベンダーは作るのがゴール。事業会社はシス テムを作ってからが本番。ここからビジネス がスタート。我々は⼀緒に歩む真のパート ナーを探している。 7
8. クラウド運⽤の現状と課題 8 1. システムの複雑化 2. オンプレになかった運⽤ 3. カルチャーギャップ 4. 認知的負荷の増⼤
9. クラウド運⽤の現状と課題 9 1. システムの複雑化 2. オンプレになかった運⽤ 3. カルチャーギャップ 4. 認知的負荷の増⼤
10. システムの複雑化 • ⼩さく始めたクラウド活⽤ ◦ 利⽤して何年？ ◦ 利⽤製品の数は？ ◦ AWSアカウント数は？ ◦ 作ったシステムの数は？ ◦ 関わった⼈間の数は？ • 必要な知⾒や技術領域が複雑多岐、全体的な⾒通しが悪 くなってきている 10
11. システムの複雑化 ⽇本のパブリッククラウドサービス市場規模の推移及び予測 11 引⽤：令和5年 情報通信⽩書 • 2024-2026：15%〜20%成⻑ • 2026年は4兆円+ • システム規模拡⼤、製品数の拡 ⼤、関係者が増加、複雑さが増え 続ける
12. クラウド運⽤の現状と課題 12 1. システムの複雑化 2. オンプレになかった運⽤ 3. カルチャーギャップ 4. 認知的負荷の増⼤
13. オンプレになかった運⽤ クラウド特有の運⽤ • コスト • セキュリィ(CSPM) • 機能アップデート追従 • アカウント発⾏ • ルート管理 • and more… 責任共有モデルから⾒えない運⽤ 13 クラウドにしかない運⽤ → リフト&シフトで漏れがち AWS責任共有モデル
14. クラウド運⽤の現状と課題 14 1. システムの複雑化 2. オンプレになかった運⽤ 3. カルチャーギャップ 4. 認知的負荷の増⼤
15. カルチャーギャップ • SoE と SoR というシステム特性 • SoE（System of Engagement） ◦ 顧客中⼼とした顧客体験の向上 ◦ 顧客のフィードバックを迅速に取り⼊れ、改善を⾏う⽂化 ◦ 市場の変化に素早く対応し、新しい機能やサービスを短期間でリ リースする ◦ 新しい技術や⼿法を積極的に取り⼊れる⽂化やトライ&エラー⽂ 化 15
16. カルチャーギャップ • SoR（System of Record） ◦ 企業の核⼼データを管理、信頼性と安定性を最優先 ◦ ダウンタイムやデータの消失は許容されないため、厳格な プロセスと⼿順が重視 ◦ データの正確性がデータの⼊⼒、保存、管理に関する厳密 な規則とガイドラインが存在し⽅やコンプラを重視 ◦ 継続的な改善（Kaizen）の⽂化があり、⼩さな改善を積み 重ねる⽂化 カルチャーギャップによるチームごとの知識や運⽤のばらつき 16
17. クラウド運⽤の現状と課題 17 1. システムの複雑化 2. オンプレになかった運⽤ 3. カルチャー 4. 認知的負荷の増⼤
18. 認知的負荷の増⼤ 複雑化したシステム、多数の関係者、個別対応、機能アップデー ト → 覚えることや考えることが増え続ける 認知的負荷が⾼いと⽣産性が落ちる 18
19. 認知的負荷の増⼤ 認知負荷の種類 • 内在的負荷: 学ぶことの難易度。例えば、新しいツールの基本的な概念や 操作⽅法の学習 • 外在的負荷: 学ぶ環境による負担。例えば、オンボーディングがなく、属 ⼈的なインプット、古い情報と新しい情報が混在 • 関連的負荷: 学んでいることを他の知識との結びつける難易度。例えば、 情報が点在していて全体像が⾒えないと負荷が⾼い 19
20. プラットフォームチーム ⽴ち上げ編 20
21. チーム⽴ち上げの背景 • システムの複雑性が増加し続ける • オンプレになかったプラットフォームの運⽤ • カルチャーギャップによる運⽤のばらつき • 認知的負荷が⾼いことによる⽣産性の低下 これらを解決することで、ビジネス貢献へ！ 21
22. プラットフォームエンジニアリングとは • ガートナーが発表した「戦略的テクノロジのトップ‧トレンド」2024年版では10 の技術トレンドの1つとしてプラットフォームエンジニアリングを取り上げてお り、その注⽬度が⾼い(他にはAIの信頼性、AIの⺠主化などがある) • 2026年までに約80％の組織がプラットフォームエンジニアリングチームを持つと 予測 • プラットフォームエンジニアリングは、近代的なソフトウェアツールやアーキテ クチャの複雑さから⽣じる認知負荷を軽減するために登場 • 開発者の⽣産性を向上させ、開発者体験を改善するための内部開発者プラット フォームを構築し運⽤する • 企業は迅速かつ効率的にソフトウェアを提供し、ビジネス価値を最⼤化する 22 引⽤：ガートナー
23. プラットフォームエンジニアリングとは 23 引⽤：ガートナー • プラットフォームとして情報を整備 ◦ 再利⽤可能なコンポーネント(例:ライ ブラリ) ◦ ツール(例：最適チェックツール/デプ ロイツール) ◦ ナレッジ(ガイドライン/導⼊⼿順) ◦ プラットフォームサービス(認証基 盤、Git、デプロイツール) • 複雑なインフラをより活⽤しやすくプラッ トフォーム化 • 開発者ポータルとして情報を提供
24. 違い Q: プラットフォームエンジニアリング、CCoE、SREの違いは？ A: 排他的存在ではなく重なる部分も多いが、アプローチが異なる 24 プラットフォーム エンジニアリング CCoE SRE 焦点 開発者向けの統⼀プ ラットフォーム クラウド戦略とガバナ ンス システムの信頼性と可 ⽤性 主な活動 ツールとインフラの標 準化、⾃動化 コスト管理、セキュリ ティ、教育 モニタリング、インシ デント管理、⾃動化 利点 開発者⽣産性の向上、 ⼀貫性 コスト削減、セキュリ ティ強化 信頼性向上、迅速な障 害対応
25. ⽴ち上げにやったこと 1. ゴール設計 2. 組織設計 3. 情報再利⽤設計 4. 統制と継続 25
26. ⽴ち上げにやったこと 1. ゴール設計 2. 組織設計 3. 情報再利⽤設計 4. 統制と継続 26
27. 1. ゴール設計 プラットフォームチームは、なんのために存在するチームなの か？何を実現するチームなのか？を定義します • なんのために存在？ ◦ システムの運⽤を安全で⾼速化する ◦ アプリ開発チームへ貢献することで競争優位性に貢献する • 何を提供するのか？ ◦ プラットフォームの企画開発運⽤に責任を持ち全体最適を ⾏うことで認知的負荷を下げる 27
28. ⽴ち上げにやったこと 1. ゴール設計 2. 組織設計 3. 情報再利⽤設計 4. 統制と継続 28
29. 2. 組織設計 各チームの役割を定義し、スムーズなチーム連携を⽬指す。 例： • アプリケーションチーム ◦ 個別アプリケーションの導⼊とライフサイクル • 運⽤チーム ◦ 個別システムの⽇々の運⽤、障害対応 • プラットフォームチーム ◦ クラウド全体の最適化と統制 29
30. 2. 組織設計 チーム間連携のイメージ 30 プラットフォームチームが提供すること • プラットフォームの開発運⽤ ◦ アカウント管理 ◦ コスト管理 ◦ セキュリティ管理 • ナレッジの提供 ◦ ガイドライン ◦ フレームワーク ◦ ツール • 統制 ◦ 発⾒的統制(モニタリング) ◦ 予防適当性(ガードレール) ◦ 是正適当性(クロージング)
31. ⽴ち上げにやったこと 1. ゴール設計 2. 組織設計 3. 情報再利⽤設計 4. 統制と継続 31
32. 3. 再利⽤可能設計 認知的負荷を下げる、かつ継続的にナレッジを蓄積するための情 報設計 プラットフォームチームポータルサイトを構築 • 最新の情報としてメンテされている • アプリチームが初めて訪れてもわかるように、Getting Started を⽤意 • wiki の⽬次設計 32
33. ⽴ち上げにやったこと 1. ゴール設計 2. 組織設計 3. 再利⽤設計 4. 統制と継続 33
34. 4. 統制と継続 統制のプロセスを定義し、クイックウィンからの脱却 34
35. プラットフォームチーム 実践編 35
36. 実践でやったこと 1. 対応スコープ 2. プラットフォームポータルサイト構築 3. 統制と継続 コスト編 4. 統制と継続 セキュリティ編 36
37. 実践でやったこと 1. 対応スコープ 2. プラットフォームポータルサイト構築 3. 統制と継続 コスト編 4. 統制と継続 セキュリティ編 37
38. 対応スコープ プラットフォームチーム対応スコープ 38 モニタリング オペレーション 障害対応 トリアージ アカウント管理 セキュリティ コスト 専⽤ポータル 改善提案
39. 実践でやったこと 1. 対応スコープ 2. プラットフォームポータルサイト構築 3. 統制と継続 コスト編 4. 統制と継続 セキュリティ編 39
40. プラットフォームポータルサイト構築 ポータルサイトに設けた機能群の⼀部をご紹介します。Wikiにてポータルサイトを構築してい ます。 • 窓⼝ ◦ AWSアカウント発⾏(ネットワークやSecurity Hubなど必要な初期設定済みで発⾏) ◦ IAMユーザー発⾏(SSOでの運⽤) ◦ 技術問い合わせ(クラウドや監視など共通SaaS製品に関するサポート) • ガイドライン ◦ システム導⼊ガイドライン(新規プロジェクト向け) ◦ セキュリティガイドライン(共通製品導⼊や導⼊後のプロセス) ◦ コストガイドライン(コストに関する注意事項) ◦ ツール導⼊⼿順(監視や共通セキュリティ製品などの導⼊) 40
41. 実践でやったこと 1. 対応スコープ 2. プラットフォームポータルサイト構築 3. 統制と継続 コスト編 4. 統制と継続 セキュリティ編 41
42. 統制と継続 コスト編 コスト編、実際の運⽤の⼀部をご紹介 • ⽉次分析レポート • コストアノマリー これらをワンショットではなく定期実⾏でき るように運⽤ 42
43. 統制と継続 コスト編 ⽉次分析レポートで検知したこと • 異常に⾼い NatGateway 利⽤費 • 異常に⾼い CloudTrail • Public IP コスト増 43
44. 統制と継続 コスト編 ⽉次分析レポートで検知したこと • 異常に⾼い NatGateway 利⽤費 ◦ S3 の経路がNAT ゲートウェイ 経由、VPCエンドポイント経 由へ変更 • 異常に⾼い CloudTrail ◦ 誤って複数設定されていた • Public IP コスト増 ◦ 料⾦体系変更によるコスト変化 44
45. 統制と継続 コスト編 コストアノマリーで検知した⽉間数 • $100未満 30+件 • $100-$500 10件 • $500以上 5件 45
46. 統制と継続 コスト編 コストアノマリーで検知した⽉間数 • $100未満 30+件 • $100-$500 10件 • $500以上 5件 分析の結果、新しいEC2/RDSリソース追加やインスタンスタイプ の変更を検知。誤検知が多いため、判断基準やアラートのしきい 値チューニングが必要。 46
47. 実践でやったこと 1. 対応スコープ 2. プラットフォームポータルサイト構築 3. 統制と継続 コスト編 4. 統制と継続 セキュリティ編 47
48. 統制と継続 セキュリティ編 セキュリティ編、実際の運⽤の⼀部をご紹介 • 導⼊ガイド(SSM / Security Hub / Inspector /etc) • 導⼊サポート • 導⼊後の検知と通知プロセス これらをワンショットではなく再現性を持ち、プラッ トフォームとして運⽤ 48
49. 統制と継続 セキュリティ編 導⼊したガードレール/⾃動修復 • 不正利⽤防⽌ ◦ ⼤きいインスタンス利⽤制限 ◦ 海外リージョン制限 • 暗号化⾃動化(EBS/S3) • SSH/RDPフルアクセス禁⽌ 49
50. まとめ 50
51. まとめ プラットフォームエンジニアリングを導⼊して1年半の振り返り • 属⼈化状態 → プロセス設計、明⽂化の⽇々だった • アプリチームの認知的負荷を⼀定度軽減できた • クラウドのコスト削減ができた(アノマリー/⽉次分析) • 属⼈化しない、再現性のある活動を作れた • 緊急脆弱性対応をナレッジ集約し迅速に展開できた • 結果的に、CCoEよりの活動が多かった 51
52. まとめ 運営してみての課題 • 頼られすぎる ◦ あくまで主はアプリチーム、プラットフォームとして利⽤してもらう ◦ アプリチーム毎に知識レベルが違い、⼊り具合のバランスが難しい ◦ プラットフォームチームで作業肩代わりしすぎると、役割曖昧に ◦ また緊急時にアプリチームで迅速な対応ができなくなる可能性 • ツールの提供でさらなる認知的負荷軽減へ(ボタンポチで終わり) • プラットフォームチームの社内啓蒙活動(もっとうまく活⽤してもらう) • 定型化できたらオペレーションチームへの引き継ぎ(さらなる安定) プラットフォームエンジニアリングの道は続く！！ 52