2017年4月25日、東京で開催されたDevOpsDays Tokyo 2017へ参加してきました。イベントの模様をご報告します。

▼ ハイライト
1. 技術者視点でみるDevOps
2. Habitatの世界へようこそ

1. 技術者視点でみるDevOps

　Value Stream Mappingは製品やサービスを顧客に届けるために必要なプロセスを分析するのに使用されます。WIKIPEDIAではこんな説明でした。

• Value stream mapping has supporting methods that are often used in Lean environments to analyze and design flows at the system level (across multiple processes).

引用元：WIKIPEDIA

　Value Stream Mappingを作成するうえで重要なポイントは、lead-time(期間)、process-time(実際の時間) を記載していくことです。どんなプロセスを進めるうえでも、大きな無駄を減らす、または気づくことができます。

　今回、セッションの講師の方が実際に手書きで IT技術、プロセス(タイトル、内容、人数、役割、実際の担当者名）、おおよそのlead-time、process-time を一括りに、そして工程の最後から記載、ということを具体的に説明していました。バリューストリームマッピングのメリットを大別すると下記の通りです。

1-1. 改善ポイントを見つけやすい

　どこを改善していけばよいのか、lead-time の大きな無駄はどこか、簡単に確認することができます。自身の担当範囲だけでなく、目標を達成するための各工程で関係する人達を可能なかぎり集め、共有していくことが成功へ導く鍵となります。

1-2. 自動化するポイントを見つけやすい

　無駄を明示するだけでなく、IT技術を利用して自動化できそうなプロセスを発見することができます。

1-3. プロセスの共通認識

　各関係者でぼんやりとしていたプロセスを明らかにして参加している関係者内で結果プロセスの共有ができます。

1-4. 価値を示せる

　関係者への共有だけでなく、無駄と思われる工程を明確に示すことで上位層への報告に必要な資料として利用できます。

1-5. ボトムアップによる現場モチベーション向上

　上長から指示されて仕方なく動くのではなく、現場で課題、改善点を見つけて動くことで自分自身の行動が周囲を動かし改善していることが感じられ、現場のモチベーションも高まります。

　また、講師の方のアドバイスとして、明示化しても何らかのしがらみ等でどうしても首を立てに振らない上長へは、”ミラクルクエスチョン”を使い、仮に全権委任されていた場合どこを改善すべきか答えてください、といった問いかけもしてみてください、ということが印象に残りました。

　Value Stream Mapping の考え方は元々新しいものではなく製造業の生産現場にて昔から実施されていたものですが、DevOps 化を進めるのに有効な手段として再注目されています。

　とある現場では Value Stream Mapping を使ってから DevOps 的にアプリケーション開発工程を改善することで8.5ヶ月のlead-timeが1週間になったこともあるとのこと。すべてのケースに当てはめられるものではないかもしれませんが、まずはホワイトボードに殴り書きで記載してみて“業務にムダ”がないか見える化してみることから始めるのも良いかもしれません。

2. Habitatの世界へようこそ

　午前中のKeynoteで登壇したAdam Jacob（ChefのCTO）もMichael Ducyもスケール（拡張性）についてはそんなに問題視しなくてもよい、という趣旨の話をしていました。

2-1. スケール（拡張性）が重要でない3つの理由

1. 拡張に関する問題まだ発生していないのでは？
2. まずプロダクトまたはサービスをリリースする。その後、拡張について問題となったときに初めて心配をしていけばよいのでは？（プロダクトアウト優先)
3. 改めて拡張について問題となったとき、マイクロサービスのアーキテクチャーだとより移行がしやすい（後で記述します）

　マイクロサービスの開発では、アジャイルとCI/CD（Continuous Integration：継続的インテグレーション、Continuous Deployment：継続的デリバリ）ツールチェーンが必要となります。
また、IndeedのMatteo Taddeiも同様のことを推奨していますが、マイクロサービス開発にあたっては、クロスファンクション機能を持つチーム編成を推奨しています（違う部門からメンバーを募ることが理想的）。

　Michaelが提示した「マイクロサービス」に求められる条件は以下4つです。

1. サービスのコンポーネント化
2. 情報単位のエンドポイント定義
3. 分散化
4. 自動化展開

2-2. Habitatの役割

　さてここからはChefが提供しているHabitatを機能別にみていきたいと思います。Habitatはマイクロサービスの“移行時に”その威力を発揮します。

• 従来のシステムはインフラの自動化とアプリケーションのデプロイメントを分離（Chef, Ansible, Puppetなど)
• アプリケーションはそれぞれ最小構成のOS（busybox）が含まれる。複数の機器に同時にインストールし、異なるカーネルを管理することができる
• 複数のカーネルを相互接続し、コンポーネント間の通信を管理し、その通信は、Gossipプロトコルによる独自の実装を通じて実施される
• ソースコードの更新の結果として継続的なデプロイメントがデフォルトで実施されるようになる

　これらのコンセプトについてAdamは数日で概念を完成させました。コンテナを使用する場合ですが、最初に必要となるすべての依存オブジェクトをインストールした上で、アプリケーションをインストールします。

　これはたいていの場合、さまざまなシステム（例：Heat + Ansible）、時にはさまざまなユーザーによって実行されます。Habitatはアプリケーションの設定の中心となるものです。

　開発者がアプリケーションに関連するそれぞれの依存するソフトを設定ファイルに書き込み、Habitatは最小構成のアプリケーションをサポートするコンテナを実行します。
　また、継続的デリバリにおいて、同一プロセスでのコード管理を可能にします。

　Habitatは（tarballのように）パッケージ管理をしてくれるソフトパッケージ管理をしてくれますが、その使い方をみてみると　”リバースコンテナ“　として概念化できるのです。

　Adamの見解では、Chefは自動化のサイクルの手助けをしてくれるプロダクトです。

　Adamはシステムアドミン（Ops）として自身のキャリアをスタートさせ、インフラの自動管理のためにChefを作り上げました。それから長い時間を経て、開発者（Dev）としてHabitatを世界へ発表することになったのです。

　私もAdamと同様にHabitatの今後の可能性を考えると、それだけでわくわくします。