マイクロサービスアーキテクチャの正しい設計 - QCon NYで学んだMichael Bryzak氏の教訓
1 マイクロサービスにまつわる一般的な誤解:
マイクロサービスでは、各チームが自らのタスクに最適なプログラミング言語とフレームワークを選択することができる
"コードの自動生成はよくない"、という考え方だ
イベントログは真実を語る資料でなければならない
2 APIの運用
Flow.ioのアーキテクチャが紹介された。そのひとつが、JSONで記述されたリソース指向のAPI定義スキーマである。これにより、エンティティとそれに対応するプロパティをすべて、適切なメタデータとともに定義することが可能になる。スキーマ定義ファイルはGit DVCSに格納され、継続的インテグレーションが実践されている。一連のテストによってAPIセット全体の一貫性が保たれるとともに、事実上の高度なリンタ(linter)としても機能する。これらテストの目標は、"ひとりの人間がAPI全体を記述した"という認識をエンジニアがもつべきである、ということだ。エンジニアリングチームでは、オープンソースのapibuilder.ioツールをテストと組み合わせて使用している。これによって、API設計フェーズにおけるエラーの防止と潜在的な変化点の検出が可能になる。apibuilder CLIユーティリティを使えば、リソースAPIとルート(Flow.ioでは、おもにPlay 2フレームワークで記述されている)に関連付けられたコードを生成および更新することができる。APIクライアントのコードも自動生成可能である。生成されるコードには、高品質かつ高速なテストが可能なモッククライアントも含まれる。Flow.ioのアーキテクチャ内では記録システムがAPI仕様である、とBryzek氏は述べている。コードを自動生成することで、"実際に仕様に準拠している"ことが保証されるのである。
3 まとめ
APIやイベントよりも先にスキーマを設計すべきであり、APIの直接コールよりもイベントのコンシュームを選択すべきである、と述べた。デプロイやコード生成、依存性管理といったタスクに重点を置きながら、適切かつ効果的な自動化に投資することが必要だ。また、品質を向上し、メンテナンスを合理化し、継続的デリバリを可能にするために、"驚異的かつシンプルな"テストの記述に努め、それを可能にする必要がある。
Comments