BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース マイクロサービス内の依存性地獄をコントロールするには - Michael Bryzak氏の講演より

マイクロサービス内の依存性地獄をコントロールするには - Michael Bryzak氏の講演より

ブックマーク

原文(投稿日:2015/06/13)へのリンク

Giltの共同創設者で前CTOのMichael Bryzek氏がQCon New Yorkで,‘依存性地獄(dependency hell)’がマイクロサービスプラットフォームのデリバリとメンテナンスに与える影響について講演した。API設計を‘ファーストクラス’にすること,前方および後方互換性を確保すること,正確なドキュメントを提供すること,クライアントライブラリを用意すること – これらを行うことで依存性地獄は緩和できるはずだ,と氏は提案する。

氏はWikipediaの“Dependency Hell”のエントリを引用して,講演の聴衆にこのフレーズを紹介した上で,依存性地獄とは,ほとんどすべての開発者がそのキャリアの上で目撃したことがあるはずのものだ,と説明した。

依存性地獄というのは,他のソフトウェアパッケージの特定バージョンに依存するソフトウェアパッケージをインストールした,一部のソフトウェアユーザのフラストレーションを表現した俗称です。

Bryzek氏は次に,高級ブランドをフラッシュ販売するEコマースサイトであるGilt.comが,5年の歳月をかけて,従来のRuby on RailsのモノシリックスタックからScalaベースのマイクロサービスプラットフォームに移行した時の状況について議論した。この移行は,技術チームが150名以上に拡大した点と合わせて,使用するライブラリを中心とする依存関係をどのように管理するか,という問題意識をチームに抱かせるきっかけになった。

依存性管理に伴う苦痛を和らげるために氏は,4つの戦略を提案する。

  • API設計はファーストクラスであるべき
  • 前方および後方互換性
  • 正確なドキュメント
  • クライアントライブラリの作成

これら戦略のいくつかは適切なツールを使用することで実現可能である,と氏は提案して,その目的のためにapidocというScalaベースのツールを開発した。apidocは既存のソフトウェアプロセスやランタイムへの外部依存性を持たないオープンソースソフトウェアで,SaaS(Software as a Service)として自由に使用できる。Giltではすでに100以上のサービスがapidocで開発されている,とBryzek氏はコメントしている。

前述した個々の戦略を説明する上で氏が指摘したのは,APの設計とそれに関連するデータは,システムにおいて最も変更の難しいものであるという点だ。従って,それらは事前設計されるべきであり,関連するアーティファクトは設計プロセスに組み入れられた上で,サービスと,それを利用するクライアントの間で適切であることが保証されなければならない。本質的に“スキーマファースト設計”なのだ。

APIあるいはクライアントライブラリの後方互換性の確保に関して氏が指摘するのは,APIの変更時には古いレコードの処理をイメージする必要がある,という点だ。APIに追加されたフィールドは省略可能にするか,あるいは適切なデフォルト値を持たなければならない,フィールドの名前を変更してはならない – そうでなければ,新たなモデルを導入して,適切なマイグレーションパスを提供する必要がある。

前方互換性も重要な検討事項である。このシナリオによる開発者には,新しいデータサービスに通知される,新しいメッセージをイメージすることが求められる。Postelの法則のいう“送信するものに関しては厳密に、受信するものに関しては寛容に”というものが,この議論には当てはまる。API(とそれに対応するクライアントライブラリ)は,利用者の便宜のためにバージョニングされなければならない。セマンティックバージョニングはそのテクニックのひとつだ。

その他,前方互換性を確立する上で必要な考慮事項としては,列挙型の使用に対する注意がある。例えば,Apache AvroApache Thriftのようなバイナリインターフェース定義言語を使用するのであれば,APIのデータ構造内に未知のフィールドが発生した場合にはエラーを投げるように注意しなくてはならない。APIあるいはクライアントライブラリ内に変更があった場合には,ツールがそれを明確に表示できれば理想的である。apidocはこの機能を提供する。

APIの正確なドキュメントも不可欠だ。これは例えば,Swagger 2.0のようなツールを使うなどして,自動的に生成することもできる。さらに氏は,APIからクライアントライブラリを自動生成することについても論じている。最初は懐疑的だったが,現在ではその方法にもメリットはあり得ると氏は考えている。例えば,定型的なAPI利用コードを削除(あるいはクライアントライブラリ内に隠蔽)すしたり,サービス全体のフィールドやアクションの名称の一貫性を維持することが可能になる。ただし,(依存性地獄のスタックに飲み込まれないように)ライブラリの外部依存性を最小限にするための注意が必要である,開発者が喜んで使ってくれるようなライブラリを作ることは非常に難しい,といった課題もある。

Michael Bryzek氏の講演“Microservices and the art of taming the Dependency Hell Monster”に関する詳細は,QCon NewYork 2015のWebサイトで見ることができる。また,acidocツールの詳しい情報については,プロジェクトのGitHubサイトやGilt Techブログを参照してほしい。

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

BT