ChefConf 2015 レポート (part 7) #getchef

2015年3月31日から4月2日まで実施されたChefConf 2015の現地レポートpart7です。

ChefConf 2015 レポート Part1

ChefConf 2015 レポート Part2

ChefConf 2015 レポート Part3

ChefConf 2015 レポート Part4

ChefConf 2015 レポート Part5

ChefConf 2015 レポート Part6

---

Keynote: Lean Configuration Management - Jez Humble

• 企業もつ典型的なモデル
• 上記のモデルでのソフトウェアの開発における問題は、時間がかかりすぎる事。（ビジネス要求から発生した要件がエンジニアリングを通って開発が行われ、最終的にシステム運用者に渡されるプロセスでは、変化の激しい今日の市場では時間がかかりすぎる）

• その対策としてアジャイル開発が導入されるが、開発部門だけがアジャイル化する事によって発生する問題がかえって多くなる。
• • ビジネス側は開発者のスクラム参加のために時間を消費する
  • オペレーションはコードデリバリーの変化に混乱する
• オペレーション部隊は、特に従来のプロセスを変化させない事が仕事：アジャイル開発の導入には基本的に反論する組織である事は劉偉すべき

• 開発者が先行してアジャイル開発を導入する事によって生まれる典型的なパターン。
• Water - Scrum - Fall (ウォーターフォール開発の途中にアジャイル開発が無理やり挿入されたモデル。
• アジャイル開発が十分に生かす事ができないケース

• Forrester社のアンケート調査：
• • 企業の中における、開発部門の位置付けをヒアリング
  • ITエンジニアリングは基本的には、決定されたビジネス戦略を支援する組織として位置づける人が多く、企業の技術的なイノベーションを牽引する組織とは思われていない。

• MITのSloan Management Schoolでのリサーチ
• • ITを活用した企業に変身するためのステップ(Maintenance ZoneからIT-Enabled Zoneへのシフト) として次の2つの方法がある。
  • • まずは効率(Effectiveness)を向上する事を目指す。
    • まずは開発／ビジネス部門との連携(Allignment)を向上する事を目指す。
  • 後者の方が、多大なITコストがかかっている事に加えて、事業での売り上げが下がっている事が判明している。

• PuppetLabs社とThoughtWorks社（Jez Humble氏がChefに移る前にいた会社）が共同で行ったDevOpsに関するアンケート
• ITの生産性を評価する項目として次の4つが最も有効である、と評価されている
• • コードの変更に要する時間
  • リリースを行う頻度
  • 障害が起きたサービスを回復させるのに要する時間
  • コードに変更を加えた際の問題の発生率

• ITの生産性に影響する要件として最も高いものを整理
• • アプリケーションのコードの管理より、システムやアプリケーションの環境のバージョン管理に時間をより多く消費している
  • ログや監視システムを通して、問題の早期発見を行っている。
  • 開発チームはコードを毎日トランクにアップデートしている
  • 開発と運用のチームが協業する事がIT生産性を向上させるのに大きく寄与している。
  • 大きな機能開発は小さなコンポーネントに分割する

• 企業の文化もIT生産性に大きく影響を及ぼす。
• 組織が企業内で情報をいかに効率良く処理しているのかによって影響を受ける。
• 情報をただ貯めることでは効果を生まない。いかに流通させるかが重要

• Amazonで実装されている、ソフトウェアサービスのデプロイメントの要求事項
• • デプロイメント間の時間 = 11.6秒
  • 一時間内の最大デプロイメント数 =  1,079個
  • 一回のデプロイメントでアップデートを受けるホストの平均台数 = 10,000台
  • 一回のデプロイメントでアップデートを受けるホストの最大の台数 = 30,000台

• Microsoftの研究報告によると、アプリケーションの開発の2／3は顧客に対する付加価値に寄与していない、ということが判明。

• Gojko Adzic氏が書いた、”Impact Mapping"という書籍からの引用
• 企業の目指すゴール（左の青い箱）を起点に、各部門で実施することができる改善／施策を解析する手法を紹介

• ITに対する投資の根拠を調査
• • 24％の人間が経済的な要件に基づいて投資判断をしている。（他は全く異なる要因で決めていると回答）

• Continuous Integrationの重要性: Googleでの事例
• • 1万人以上の開発者、2000以上のプロジェクトが、一つのコードトランクに対して統合して開発を行っている。
  • 毎分20以上のコード変更が行われている。
  • 全コード量の半分以上が、毎月必ず変更を受ける

• Googleでは、これを実現するためにテスト工程の最適化にかなり投資をしている。
• これを実現するのに4年かかっている。

• 品質を向上させるためには、検査／QAでのプロセスを強化するのではなく、設計段階から品質を作り込む仕掛けが必要である。

• Chefでは、この品質の確保を容易に、そして迅速にできるようにするための施策をChef Deliveryの重要な機能として盛り込んでいる。

• 「ウェブアーキテクチャにおけるアプリケーション開発の成功は、水平スケールに基づく、信頼できないプラットホームの上で、信頼できるソフトウェアコンポーネントの実装を継続的に行う仕組みを作ること。」
• • Amazon社のJesse Robbins氏のコメント

• 信頼できないプラットホームとは、自分のワークステーション上で開発したアプリケーションが、問題なくターゲットのプラットホーム上で稼働することを保証するための、
• • Resilience: 柔軟性
  • Security: セキュリティ
  • Scalability: スケーラビリティ
  • Deployability: 実装が容易にできること
  • Testability: テストも容易にできること
• ターゲットプラットホーム上での稼働を確認するために長い時間と労力を要するのでは問題

• AWSで実際にCEOが社内の開発者全員に送った6つのルール：
• 1. すべてのデータと機能の仕様はサービスインタフェース経由で提供する事。
  2. 開発チームはこれらのインタフェースでコミュニケートすべし
  3. 他の手法を用いたプロセス間の通信は許されない：直接的なリンク禁止、他のチームデータストアからのデータの読み込み禁止、共有メモリモデルの禁止、その他のバックドア系も禁止。唯一許されるのは、ネットワーク上のサービスインタフェースコールのみ。
  4. 仕様する技術は問わず：HTTP、Corba、Pubsub、独自プロトコル、等、Jeff Bezosとしては構わない。
  5. すべてのサービスインタフェースは、例外なく、すべての設計レベルにおいて、外部に公開できるようにする事。開発チームは、開発したインタフェースは社外にオープンに公開する事を前提とする。
  6. このルールに従わない人間はクビ。
• 特に5番目のルールは重要

• さらに、AWSのCTO, Werner Vogels氏のコメントは：”You build it, You run it.” 「コードを作った人は、運用の責任も持つ」
• 具体的には、開発責任者は、開発したコードを運用時まで責任をもって取りまとめる事を言わんとしている。

• 言わんとしている事は、従来のプロジェクトベースの開発の考え方を捨てて、一つ一つのプロジェクトを「プロダクト＝製品」として考える事が重要。

• Amazonの手法：各部門は自分の部門で使用するツール、サービス等を独自の判断で（他部門からの支援を受けず）導入する事ができるモデル。開発部門も運用部門も同じ。
• AWS EC2も元々は、外部に公開する製品サービスとして開発されている（内部ツールとして作られている、という説があるが、それは間違い）
• コンテナの技術もアプリケーションの開発段階では自動化の促進に大きく寄与するが、最終的にプラットホームとインフラ部分への実装の段階に関しては未だに人間が介在しなければいけない要件がいっぱいある。
• Chefのライフサイクル管理のコンセプトはそこをしっかり管理する事がキーポイントである。

• Chefの目指すところは、単なるシステム構成管理を行うツールとしての技術的価値ではなく、企業全体の事業戦略を大きく前進させるDevOpsのコンセプトを推し進めることにある、という事がイベント全体としてのメッセージである事がよく分かる。
• DevOpsのコンセプトに基づく開発者、運用管理者の間の協業だけではなく、経営者、営業、マーケティングも含めて、構造的なウォーターフォール型の事業の進め方から、よりダイナミックに対応できるアジャイル性の高い、DevOps手法を取り入れる事の重要性、そしてそしてそれを実現するツールとしてのChefの導入、という考え方を持つ事が重要である、とう事を主張している。

---

 

ChefConf 2015レポートは、このPart7で完了となります。今回のレポートはいかがだったでしょうか？多少でもChefConfの空気感が伝わったのであれば大変嬉しく思います。

ChefConf 2016の開催も決まっているようです。是非来年は、一緒に参加しましょう！^^

https://www.chef.io/chefconf/