1. Infrastructure as Codeと組織構造 2016/7/7 吉羽龍太郎
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee
3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話
4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる
5. よくある文化的な問題 ✤ ソフトウェア開発のベストプラクティスがそもそも導入できていない。例えば、バー ジョン管理 / 受入テスト自動化 / 継続的統合 ✤ まずこのあたりから。ソフトウェア開発でこれらができていなければインフラの話よ り前にそちらを
6. Infrastructure as Code (2) ✤ 領域はサーバの内部(いわゆるOSの設定やミドルウェアの設定)だけに限らない ✤ サービスを動かすインフラ全体(ネットワークやそもそものサービススタック全体)が 対象になり得る ✤ インフラなのかアプリなのかの境界がなくなっていく
8. “システムを設計するあらゆる組織は、 必ずその組織のコミュニケーション構造に倣った 構造を持つ設計を生み出す” コンウェイの法則
9. 組織構造による考察 (誰がInfrastructure as Codeの実装をするのか？)
10. 組織構造 (1) ✤ 開発部門とインフラ部門が独立した組織で、独立したチームのもとでプロジェクトを 実施する場合 開発部門 インフラ部門
11. 組織構造 (1)における考察 ✤ SI等でよくある組織構造。部門単位で利益確保したり部門配賦をおこなう ✤ ポテンヒットを避けるために責任分界点を明確にしたがる ✤ 強力なコントロール ✤ 部門間のコミュニケーションは文書によるものが多い (例)払い出し依頼 ✤ インフラ提供メニューを均質化しやすく、払い出しはある程度自動化可能
12. 組織構造 (1)における課題 ✤ 同じ専門性の人は一箇所に集めた方が効率的になる、という誤解 ✤ コミュニケーションのオーバーヘッドが大きい ✤ リアルタイムな対応が難しくリードタイムの考慮が必要 ✤ Infrastructure as Codeの観点でいうと初期の作業効率化や再利用性のメリットは 享受できているが、サービス全体の視点が抜けやすい ✤ 責任範囲を分けても残るポテンヒットと非効率 (例)開発チーム用の開発環境 (Vagrantとか)を誰が用意するのか問題
13. 開発部門1 開発部門2 開発部門3 組織構造 (1-1) インフラ部門
14. 組織構造 (1-1)における考察 ✤ 開発部門がどんどん増えた場合にインフラ部門側がボトルネックになる可能性 ✤ ビジネスの要求に関係なく、インフラ部門としてのSLAを基準にしてインフラが作ら れる ✤ 均質化を進めないと対応しきれなくなるのでアプリ側の要件をインフラにあわせる ことを要求しはじめる ✤ ビジネス側の論理より組織構造の制約を優先してしまっている ✤ ビジネス側、アプリ側から不満が出てくる可能性
15. 開発部門 サービスA サービスB サービスC サービスD サービスE サービスF 組織構造 (1-2) インフラ部門
16. 組織構造 (1-2)における考察 ✤ 開発とインフラで部門や責務を分離しているのにマイクロサービス化しようとした例 ✤ 各サービス側はI/Fの一貫性を維持しながらサービスの更新をおこなっていくが、イ ンフラの変更が重荷になる（基本的には破綻の方向） ✤ インフラ側はいつ何をやるべきか制御しきれずリードタイムが安定しない ✤ 個々のサービスまで把握できないので純粋にインフラだけを提供する形となり運用 まで責任を持つことは相当難しい ✤ セルフサービス化「しない」意味がなくなってくる
17. (根深い) 責任分界点問題 ファイル保存用S3 Bucket ✤ 例えばAWS上でWeb層が自動伸縮 (Auto Scaling)する例において… ✤ AMI作成はアプリのデプロイなのか、 インフラなのか？ ✤ Auto Scalingの設定はどっちの担当 なのか？ ✤ 急に設定変更が必要なときはどうす るのか？ Auto Scaling group AMI Web用Public Subnet Web用Public Subnet DB用Private Subnet DB用Private Subnet AZ-c AZ-a サービス用VPC
18. 根本的にアプリとインフラの境界線は曖昧。 そのつなぎ方 = アーキテクチャである。
19. 組織構造 (2) ✤ 開発部門とインフラ部門が独立した組織だが、プロジェクト単位でバーチャルチー ムを作る構造 開発部門 インフラ部門
20. 組織構造 (2)における考察 ✤ インフラ担当がチームに参加するためコミュニケーションのオーバーヘッドが減る ✤ 一方で複数プロジェクトを兼任した場合インフラチームではなく個人に負荷が偏っ てしまう ✤ 部門単位の利益や稼働率といった前述の問題は解消しきれない可能性は残る ✤ 個人の能力への依存を避けるために、インフラ部門での情報やベストプラクティス の共有が必要になる ✤ アーキテクチャはアプリケーション個別に最適化しやすい ✤ 運用に入ったあとも体制を維持できれば変化に対応し続けられる
21. 組織構造 (3) ✤ 製品単位でチームを作り、その中にインフラエンジニアを含める。製品はもっと粒度 の小さいサービスであることもある 製品Aチーム 製品Bチーム 製品Cチーム
22. 組織構造 (3)における考察 ✤ サービスをゴールにできるので集中しやすい ✤ チーム内でフルスタックに構成したチームで一番変化に強くなる ✤ 必ずしもインフラ専任とは限らずアプリ開発者のうちインフラもできるエンジニア が担当することもある ✤ 他の製品チームをあまり意識することがないので全製品をまたいだ一貫性は担保さ れない可能性 ✤ 認証やセキュリティ等をどう要求基準にあわせるかについてはコントロールが必要
23. 組織構造 (3-1) 製品Aチーム ✤ 先ほどのチームに加えて標準化 (や最低限の基盤)・セキュリティ チームを用意する（仮想チーム であることも） 製品Bチーム セキュリティ/標準化 製品Cチーム
24. 組織構造 (3-1)における考察 ✤ 前述の組織構成を活かす一方で、リスクとなりそうな箇所を標準化したり、共通系 サービスを提供したり、必要な部品を提供していく。社内オープンソース ✤ 例えばクラウドを利用している場合はセキュリティ設定済みのイメージ、Terraform のスクリプト、各種ガイドラインなど。場合によっては定期的に検査をおこなうような 形 ✤ チームの自律性＋外部からの最低限守るべきルールの提供という形になるためス ピード・自由度・安全のバランスが取れる ✤ Infrastructure as Codeやマイクロサービスのメリットを最も享受しやすい ✤ AmazonとかNetflixはこんな感じ
25. 責任範囲マトリクス (例) RACIマトリクス アプリエンジニア インフラエンジニア 標準化/共通基盤チーム セキュリティチーム ネットワーク 専用線接続 CIDRブロック割当 サブネット切り出し VPN設定 I I I I C C C C R/A R/A R/A R/A I I I I I C R/A I I C C R/A R/A I C I ミドルウェア導入 アプリケーション導入 AutoScaling設定 課金管理 AWSアカウント払い出し R/A R/A R/A R/A C C I I I I I I I C R/A I AWS利用料金管理 I C R/A I ドメイン名払い出し 仮想マシン ベースイメージ作成 インスタンス起動 R：実行責任者（Responsible) / A：説明責任者（Accountable) / C：協業先（Consulted）/ I：報告先（Informed）
26. 組織構造別の整理 (1) 外部部門へ依頼 (2) 部門またぎチーム (3) ワンチーム 初期構築 ◯ ◯ ◯ 運用・障害対応 △ ◯ ◯ コミュニケーション ✕ ◯ ◯ リードタイム ✕ ◯ ◯ 汎用性 / 一貫性 ◎ ◯ △ 自由度 △ ◯ ◎ サービスの視点 △ ◯ ◎
27. 文化面でのチャレンジ ✤ モダンなソフトウェア開発プロセスに対するまっとうな感覚を養う必要 ✤ 顧客への価値の提供サイクルを最適化しようとした場合、それにあった組織構造が 必要 ✤ ただしいきなりやろうとすると文化的な抵抗を多く受ける (アジャイル適用で通った 道) ✤ 小さくても良いのでまずうまくいく実例を意地でも作る ✤ 技術面以上に人間系が泥臭いことを覚悟する
