大きさよりも独立性

マイクロサービスは小さく作ろうとすると失敗する（2/2 ページ）

公開 2017年03月28日 09時01分

著者

荒井亜子

[TechTargetジャパン]

印刷する

これからマイクロサービスへ取り組む企業へ

　ここまでマイクロサービスのアーキテクチャを中心に紹介してきた。最後に、飯島氏がアーキテクチャとセットで考えるべきだと強調する留意事項について書き留めておく。

利用者視点の“おもてなしAPI”を

　デジタルビジネスを目指してマイクロサービスを開発するなら、API公開は必須事項といえる。「APIはビジネスチャンスであり商品そのもの。商品は使われて初めて意味を持つ。APIの利用者が誰で、どんなメリットをもたらすのか、そのシナリオを先に考える必要がある」（飯島氏）。APIの利用シナリオが定まれば、マイクロサービスおよびアプリケーションのアジリティをどこに持たせるかが見えてくる。また「マイクロサービスとAPIのライフサイクルを分けることも重要」（同氏）だという。サービス側に変更を加えても、利用者がいるAPIは変更を極力控えた方がよい。

アジャイル開発＋自動化

　マイクロサービスの開発プロセスは、アジャイル開発手法を取り入れれば終わりではない。「設計、実装、テスト、デプロイ、リリースといったプロセスの後に、利用者からのフィードバックを受けて次のバージョンへの改良を繰り返す。それぞれの開発ステップでどれだけ自動化ができるかが鍵」（飯島氏）

さまざまな稼働環境

　モノリシックなアプリケーションと比べて、マイクロサービスの内部構成はシンプルだ。一方で小さいサービスをたくさん稼働させるため管理は複雑になる。管理項目の例としては

マイクロサービス間のコミュニケーションやマイクロサービスの監視
マイクロサービスとデータベース間のメッセージング
APIが外部と通信する際のセキュリティ対策
テストやデプロイの自動化

などが挙げられるという。一気に全てに対策しようとしたり、自力で全ての対策を講じたりするのは大変だ。飯島氏は、まずはマイクロサービスの適用範囲を小規模で始め、必要に応じてマイクロサービスの管理機能を持つPaaSや運用自動化ツール、テレメトリング（遠隔監視）ツールを活用することを勧める。「大規模環境であれば『Cloud Foundry』『OpenShift』といった実績のあるPaaS基盤製品で実行環境を構築してもよいかもしれない」と同氏はアドバイスする。

チーム構成は小規模で独立

　開発チームについてもマイクロサービス同様に小規模で独立して動けることが重要だという。「2～6人程度で、他のメンバーの作業内容を把握できる距離感でいることが大事」と飯島氏は語る。メンバーは原則、ステップ別分業ではなく、設計、コーディング、デプロイ、運用、フィードバックといった一連の作業を1人で担当する。「ライフサイクル全てを担うスキルセットが必要」とのことだ。

　飯島氏は、マイクロサービスで全ての機能を実装することは勧めていない。変化が激しくデリバリースピードが求められるタイプの機能には向いているが、変化が少なくはじめから作り込むタイプには向いていないとのことだ。コツは「1回で完成系を目指さないこと。マイクロサービスを作ろうしないこと」だという。モノリシックなアプリケーションを作り替えるのであれば、依存性を減らしながらコンポーネントに分割していくことがポイントだと念を押した。