デプロイ時の面倒な定義作成は「Kustomize」を使って簡単＆効率化
作成したマイクロサービスのデプロイメントは、すでにMicrosoft Azureの仮想ネットワーク（VNet）上に仮想サーバーを構築していたため、それを利用した。さらにAzure Cosmos DBやAzure SQL Databaseのマネージドサービスを使うと、このVLANの中にエンドポイント接続できる。その結果、システム全体を仮想ネットワークの中で完結できた。
「あとはノードサイズやノード数を設定して作成を進めていきます。ここで注意するのは、マイクロサービスでは大量のIPを消費するので、あらかじめ十分なサイズのサブネットを仮想ネットワークに作成しておくことです」
次に必要となるのが、Dockerで作ったそれぞれのサービスの設定ファイルを、Spring Bootに渡していく仕組みだ。KubernetesではConfigMapを使って定義しておくと、コンテナの側で起動時にファイルとしてマップされるようになっている。
またマイクロサービスのデプロイ作業は、YAMLを大量に書く必要がある。この膨大なYAMLをどう管理していくかが問題だ。この対策には「Kustomize」というツールを採用した。Kustomizeを使うと、まず共通する定義を作成し、そこから差分だけを別に定義していけるため、時間や労力がかなり節約できる。
「Kustomizeのもうひとつの良いところは、ConfigMap名にハッシュ値を入れてimmutable化できる点です。通常Kubernetesでは、ConfigMapを変更してもPodを自動では更新してくれません。この場合、名前が同じままだとKubernetesは検知してくれないので読み直す必要が生じます。しかしKustomizeを使うと、ConfigMapを変更した場合に必ず名前も変更してくれるようになります」
日進月歩の技術を積極的に取り入れ、さらなる機能向上を目指す
今回のマイクロサービス化で、もうひとつ石田氏が工夫を凝らしたのが、パフォーマンス改善の仕組みだ。移行前はモノリシックなアプリケーションだったため、関数呼び出しがマイクロ秒単位の速さを実現できていた。また近隣のサーバーとも、JDBCクエリを使って同様の速度による処理が可能だったという。
「これをマイクロサービス化してKubernetesのアーキテクチャに乗せると、格段にスピードが落ちてしまうのがわかりました。実際に計測してみたところ、従来だと7.05マイクロ秒だったのが26.07マイクロ秒となり大幅なダウンです。これではユーザーエクスペリエンスにかなり影響が出てしまいます」
これまでは「ビュー」「コントローラー」「キャッシュ」「DAO」まで、すべての階層が1つのJVMインスタンス内に収められていた。それがマイクロサービス化すると、階層が分離されて「https REST API」や「JDBC Query」の2段階を経由して処理が流れることになる。これが遅延の原因だった。
「この教訓としては、ある程度の大きな単位でロジックを切り出していくこと。マイクロサービスならとにかく細かい単位で作ればいいといった声もありますが、計測結果を見る通り、関数呼び出しを多用する場合は注意しなければいけません」
このパフォーマンス問題の解決のため、アプリ側にキャッシュ層を残すことや、非同期・並列プログラミングといった工夫を凝らしている。
「まだまだ改善していきたい部分は数多く残っており、現時点ではクリアしきれない難しい課題もあります。しかしマイクロサービス関連の技術は急速に進歩しており、その成果をいち早く取り入れながら、さらに機能や使い勝手の向上を目指していきたい」と展望を語り、石田氏はセッションを終えた。
お問い合わせ
株式会社ドリーム・アーツ
