マイクロサービスアーキテクチャーの導入はどうすればうまく進められるのか、先行事例や識者からノウハウを学ぼう。
マイクロサービスはメリットの半面、弱点もある。従来に比べて管理対象が多く、しかもそれらを連携して用いるのでテストや運用の難度が上がりがちだ。マイクロサービスの副作用といえる注意点を3つ紹介する。
1つめは、サービスが細分化される分、結合テストに手間がかかる点である。
まずマイクロサービス化により単体テストの手間は減るはずだ。レッドハットの須江伸洋テクニカルセールス本部シニアソリューションアーキテクトマネージャは「テストを局所化できるのでテストケースは少なくて済む。そうならないなら、データの分け方に失敗していたり、ドメインがきちんと分離していなかったりする原因が考えられる」と指摘する。
一方、結合テストやシステムテストでは、従来より多くのサービスを連携させる必要があるので複雑性が高まる。この課題を解決する方向性は2つある。
1つはテスト自動化の推進だ。カバレッジテストの自動化ツールは既にあるので、CI／CDパイプラインにうまく組み込んで省力化を図りたい。コンテナベースでもテストの自動化は図りやすい。例えばJCBは、リリース前にSREチームがカオスエンジニアリングツール「Gremlin」で障害テストを実施する。
もう1つの方向性は業務観点での確認である。アイムデジタルラボの鈴木雄介取締役は「システムテストの設計で大切なのは業務観点だ」と話す。ユーザー操作を模したテストで、業務としての整合を確認する。連携の数や階層が深い場合は性能への影響が懸念されるが、このテストで検証できる。
マイクロサービスの2つめの注意点は従来に比べて運用が難しくなることだ。JCBの片岡部長は「これまでのシステムはアプリケーションサーバーベースだったが、マイクロサービスで数多くのコンテナを監視しなければならない。監視対象が多くなるうえに、監視項目やアラートの設定などにも手間がかかる」と話す。
アイムデジタルラボの鈴木取締役も「分割を進めると連携が複雑になり、呼び出し回数が多くなる。ノード数が増え、それらが落ちたときの調査も大変だ」と指摘する。三越伊勢丹は分散トレーシングツール「NewRelic」を使ってシステムの状態を日々トレースしている。障害が発生すると、そのデータを活用し原因を分析する。鈴木取締役は「分散トレーシングのようなツールを使いながら、組織としてシステム全体の運用管理能力を強化したい」と話す。
