#api360 Microservies Summit 2016で学んだこと

API Academy #api360 Microservice Summit というイベントがニューヨークで開催され，マイクロサービスの専門家たちが，マイクロサービスの現状や関連アーキテクチャ，組織におけるプロセスや技術的問題について，自らの考えを発表した。そこからは，マイクロサービスのメリットを最大限に活かすためには，技術的および組織的インフラストラクチャをサポートするための投資が必要であること / ビジネス能力や自己統治能力を備えた独立型チームなどを中心に，マイクロサービスの原理の理解に注意を払う必要があること / 開発チームと運用チームが堅牢な分散型システムの構築と運用に関するプラクティスを理解しなくてはならないこと，などの教訓を学ぶことができた。

イベントの最初には，API Academy副社長のMatt McLarty氏が，自動車とマイクロサービスの開発史を対比した説明を行なった。初期の自動車は愛好家のみを対象としたものだったが，アセンブリラインの導入によって一般大衆にも入手可能なものになった。アプリケーションをLinuxコンテナにパッケージするDockerは，この大量生産と同じような手段を提供するものと考えられる。自動車のアナロジの延長として氏は，州間高速道路マップや交通信号，ガソリンスタンドといったインフラストラクチャのサポートなしには自動車の広範な普及はあり得なかった点を指摘した上で，マイクロサービスとコンテナ技術の真のメリットを実現するためには，我々も同じようなインフラストラクチャを開発する必要がある，と主張した。

API AcademyでAPIデザインのディレクタを務めるRonnie Mitra氏は，業界の著名者による‘マイクロサービス’の定義をいくつか紹介した上で，それらがこのアーキテクチャの‘サイズ’の面に注目し過ぎているのではないか，と指摘した。システムの“周辺を単に複雑化する”ことのないように注意を払う必要があると同時に，マクロとミクロの両面からアーキテクチャと設計を実施しなくてはならない。Mitra氏は，マイクロサービスアーキテクチャで最も重要な概念はサービスバウンダリであり，システム全体の発展ペースを管理する上で一助となるものだ，と言う。組織設計と組織の文化がマイクロサービス実装の成功に果たす役割は大きい。ソフトウェア開発において，速度と安全性のトレードオフは常にあるものだが，正しく実現されたマイクロサービスの提供するセグメント化は，この２つを同時に向上させることができるのだ。

Haufe.GroupのCTOであるHolger Reinhardt氏は，‘The Automated Monolith’と題したプレゼンテーションで，モノリスからマイクロサービスへのほぼ失敗に近いマイグレーション経験から得た教訓を話してくれた。モノシリックアプリケーションを移行する最初の試みは，テストカバレッジの喪失やスコープの変化，プロジェクトの複雑化(マネージャの“開発者があとX人必要だ”という発言はその先行指標である)といった問題を引き起こし，結果的に“アジャイル(agile)ならぬフラジャイル(fragile, 脆弱なもの)なシステムに”なってしまった。Reinhardt氏は当時を振り返った時，２つの重要な概念に思い当たったという。第１の概念は，Martin Fowler氏の定義したマイクロサービスの前提条件で，その大部分は自動化に関するものだ。そして第２は，リーンを根源とする‘安定化，最適化，変換’の概念だ。同じチームによってさらなるマイグレーションの試みが実施されたが，今回は自動化を重視し，システム中の‘より早い変化’を求められる部分を優先した作業が，強化されたプロジェクト管理構造(真のアジャイルへの橋渡しとしての“ウォーターフォールアジャイル”)と相応のリーダシップの下で実施された。この第２のマイグレーションが，結果として功を奏したのだった。

次のVijay Alagarasan氏は，“Seven Microservice Antipatterns”というプレゼンテーションを行なって，以前にInfoQでも公開したことのある有益なリストを紹介した。

1. 無秩序な結合 – サービスはビジネスの目標に明確に沿ったものであると同時に，その境界外部に影響を与えようとしてはならない。
2. オートメーションの軽視 – 継続的デプロイメントは，それがまだ実現されていないのならば，必須の投資対象であり，すべての企業が目標とすべき文化的変革である。
3. レイヤードサービスアーキテクチャ – 複数のサービスによる技術的ないし物理的レイヤ構成は，デリバリの複雑性と実行時の非効率性の原因以外の何ものでもない。
4. コンシューマの承認任せ – コンシューマに頼らず，提供するサービスすべてについてテストスイートを用意し，あらゆるサービス機能やセキュリティ，パフォーマンス，エラー処理，さらには既存および将来的なコンシューマに対する消費駆動型テストをカバーしなくてはならない。
5. 手作業の構成管理 – PaaSないし継続的デプロイメントの一部として，アプリケーション構成管理ツールを使用すること。
6. バージョニングの不在 – コンシューマのスムーズなマイグレーションを可能にし，プロバイダが誰にも影響を与えず，透過的に変更をデプロイできることを保証するバージョン管理戦略を用意すること。並列して存在する製品のメジャーバージョン数を制限し，それらを管理すること。
7. すべてのサービスに対するゲートウェイ構築 – 非機能要件の可能な部分を集中的に管理および監視するためのAPI管理ソリューションに投資し，マイクロサービス構成管理に関するコンシューマの負担を軽減する。

昼食前にもうひとつ，Vanick DigitalのプリンシパルであるLou Powell氏の司会によるパネルディスカッションが行われ，jet.comのEric Ess氏，NetflixのEdge Developer ExperienceのディレクタであるSangeeta Narayanan氏，ThoughtWorksコンサルタントリーダのCassandra Shum氏，Gilt.comのSVPエンジニアであるAdrian Trenaman氏といったマイクロサービスの専門家が登壇した。ディスカッションでは結論として，“信頼できるソフトウェア技術者の採用と効率的なデリバリを可能にする環境と自律性と責務の提供”，“‘開拓者，入植者，都市計画者’モデルを採用したシステムとツーリング，プロセスの革新と安定化の促進”，“ビジネス上の利害関係者とIT関係者のコラボレーションの拡大”，“透過性，理解共有，協力を備えた効果的な文化の発展と促進”，“サーキットブレーカや‘障害復旧トレーニング’あるいはゲームセッションなどを活用した，技術的な蓄積と組織化されたシステムによる，失敗を許容する文化の計画的実現”などをあげた。

午後のセッションは，API AcademyのAPIアーキテクチャディレクタを務めるMike Amundsen氏の講話から始まった。その中で氏は，“イノベーションは経済変革の単位である”というJoseph Schumpeter氏の言葉を引用しつつ，イノベーションはどこにでもあるということを指摘すると同時に，企業が急速に革新できることの重要性を強調した。問題の解決において，(蟻がやっているように)作業を分解して協力することで，より迅速なイノベーションが可能になる，と氏は言う。ソフトウェア開発においてこのビジョンを実現する上で，マイクロサービスのアーキテクチャスタイルは有効な手段だ。‘The Fifth Discipline’で紹介されているワークを引合に出しながら，Amundsen氏は，失敗から学ぶ可能性を認めるような教育環境を構築することの必要性を主張した。ITチームは，将来を見据えた新技術を実験するための時間的猶予を与えられるべきだ。それによって関連組織が継続的に革新し，企業成長の‘Sカーブを越える’ことが可能になる。

CA technologiesのプリンシパルコンサルタントであるErik Wilde氏は“Microservices and Web Architecture”と題したプレゼンテーションの中で，SOAを“悪いこと”と見なす人の多さを指摘した。初期のWebサービスの実装はワールドワイドウェブ(WWW)の思想に基づいて作られておらず，エコシステムとしてのアーキテクチャよりもシステムのアーキテクチャを重視したものだった。マイクロサービスは，アジャイル本来の原則と継続的デリバリ，そしてDevOpsを組み合わせたという意味では，次世代SOAであるとも言える。Wilde氏は，マイクロサービスが“調和とスケールを備えた速度と安全の向上”を提供する可能性を示唆しながらも，現時点では(分散型ディレクトリなどが潜在的に必要とする)大規模エコシステム内においてサービスを検出する手段，堅牢性と柔軟性を実現する設計・管理・拡張の方法など，いくつかの“盲点”が存在していることを指摘した。そして最後に，“マイクロサービスの３つのV”，すなわちVolume – 大規模運用に供するシステムはどのようなものになるのか，Variety – クリエータとコンシューマとしてのサービス設計の違いをどのように扱うか，Velocity – システム領域の拡大に伴って，サービスとその設計の安定化をいかに図るか，の３つを指摘して，自身の講演の結論とした。

続くセッションでは，Mike Amundsen氏が，‘Sixty Years of Humanizing the Craft’で“Conwayの法則”を提案したMel Conway氏にインタビューした。その中で氏が述べたアドバイスは，‘ソリューションを分割せよ’ – 表現力豊かなドメイン固有の中間言語の存在は，その“労力に十分見あう価値のある”統合ソリューションを与えてくれる，‘静的であることを良しとせよ’ – アプリケーション開発に多数の人々が関与するためには，アルゴリズムの排除(ないし隠蔽)が必要だ，‘開発行動を簡素化せよ’ – 開発者に対して迅速なフィードバックを提供する一方で，開発者は‘プログラム’言語と‘実行’言語を区別してはならない，‘技術を人間のものにせよ’ – イベント駆動アプリケーションやトランスフォーム・インプレースなシステムは，従来型のプログラミングよりも概念的に理解しやすい。アプリケーション開発を万人向けのものにすることは，適切なツールで(ろくろを使う時のように)手-目-脳のシステムを結び付けることになる。

最終前のセッションでは，ComcastシニアフェローのJon Moore氏が，“Surviving Partial Failure in a Microservices Jungle”と題したプレゼンテーションを行なった。Moore氏は，マイクロサービスベースのアプリケーションを開発するチームは実質的に分散型システムを構築しているのであって，そのようなシステムは部分的障害に陥りやすいのではないか，という点を指摘した。部分的障害の現れ方はさまざまだが，実際にサービスが行なう処理が何であれ，ユーザによる呼び出しが起点であることは共通している。従って我々としては，その適切な緩和戦略を用意する必要がある。Moore氏は３つの戦略を提案する。すなわち，(1) サービスインターフェースのべき等性 – サービスコールの再試行によって，期待しない副作用を発生させてはならない。応答情報の効果的なキャッシュ処理はサービスの負荷軽減のみならず，一時的なエラーの隠蔽(古いデータという潜在的コストを伴うが)にも有効である。(2) 重要性による分割 – 非同期通信の利用，サービス境界の適切な定義と設定，代替(フォールバック)実装の提供など。そして (3) 可能な場合の再結合 – サービスの粗粒化により，部分的障害を最小化する。クライアントがただひとつのサービスのようなサービスの過度な細粒化，密結合(サービスAに対する任意の変更によってサービスBも変更される)，相関呼び出しなどの兆候を識別するための技術を習得する。

当日最後のセッションは，ReferWellのCTOであるIrakli Nadareishvili氏による，“Microservice Blind Spots”と題したプレゼンテーションだった。アーキテクチャスタイルとしてのマイクロサービスの採用には，個別に分離されたプロセス実行に適したコンテナ技術の台頭という背景もある。Nadareishvili氏は，現在のマイクロサービスコミュニティの関心は過度にコード中心であり，サービス境界のインターフェース設計にもっと注目すべきだ，と主張する – “サービスインターフェースの密結合はコードのそれと同じように有害であり，アーキテクチャ全体を役に立たないものにしてしまいます。” ドメイン駆動設計(DDD)とコンテキスト境界の概念は，いずれも開発者にとって，ビジネス機能をマイクロサービスベースのアプリケーションで効果的にモデル化するための有用なテクニックである。Nadareishvili氏は，マイクロサービスシステムの開発においては，イベントソーシング(ES)やコマンドクエリ責務分離(CQRS)などのイベントベースのシステム設計技術が特に効果的であると論じて，自らの講演を締め括った。

API Academy #api360イベントに関する詳細はイベントのWebサイトや，Twitterのハッシュタグ #api360で確認することができる。