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