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