運用負荷の解消に向け、マイクロサービスへの移行を決意
今回移行の対象となったのは、ドリーム・アーツが運用する「Shopらん」というアプリケーション。これは「チェーンストア・多店舗運営コミュニケーションツール」と呼ばれる、流通・小売業の本部・店舗間のコミュニケーションに特化したクラウドサービスだ。例えば、本部から各店舗に対する指示や新商品情報を送ったり、店舗の側から本部に運営状況を報告したりと、ユーザー企業の日常業務に欠かせない数々の機能を提供している。
2008年にサービスを開始し、今年で11年目を迎えた。現在の登録ユーザー数は60万件にのぼり、コードベースは約200万行。預かっているデータの総容量は23TBに達する巨大アプリケーションだ。
同社がこのアプリのマイクロサービス移行に着手したきっかけは、巨大さゆえの運用負荷の増大だった。またStruts1で開発され、JDBC経由でデータベースにMySQLを置く構成も、現在ではもはや「古臭くてモノリシックなアーキテクチャにしか見えなかった」と石田氏は振り返る。
「ビルドした200万行（165MB）をコンパイルすると30分。さらにこれを本番環境にデプロイすると、ブートだけで30分を越えてしまうので、1日に何回もデプロイしたくても、そう簡単にできません。構成管理だけはChefを使って何とか回してきたのを、ようやく今年からDockerのランタイム上で動かすようになったところでした」
とはいうものの、デプロイのたびに「30分×サーバーの台数分」の時間がかかってしまっていた。ビジネスの要求に応えるために、アクロバチックな構造も次第に増えてきた。その結果、内部の処理の流れが複雑化して、もはや手に負えないところまで来ていたという。サービスを継続するために、全面的なリファクタリングが必要なのは、誰の目にも明らかだった。
「どうせ改修するなら、今のアーキテクチャを引き継ぐのではなく、根本的に刷新したかった。そこでコンテナオーケストレーション上にマイクロサービスを乗せる仕組みにしようと考えたのです」
石田氏自身、コンテナには以前から関心を持っていたが、自分たちには手に余ると思っていた。そこに昨年あたりからKubernetes as a serviceが盛り上がってきて、これなら自分たちでもできると確信を持ったという。
「Spring Boot」と「Swagger」を組み合わせ、マイクロサービスの作成効率をアップ
新しいマイクロサービスのプラットフォームに採用したのは、「Azure Kubernetes Service（AKS）」だった。マイクロソフトが提供する、このフルマネージドのKubernetesコンテナオーケストレーションサービスを選んだ理由は、自社の既存環境との親和性だ。すでに「Shopらん」のデータストアでAzure SQL Databaseのマネージドサービスやデータベースを導入しており、処理の連携などを考慮すれば最適かつ必然的な選択だったといえよう。
マイクロサービス化で最初に着手したのは、アプリケーション対応だった。現在、稼働中のアプリのコードをいきなりマイクロサービス化してコンテナに乗せかえるのはリスクが大きいため、従来の実装を維持して万が一の場合はすぐに切り替えられるように備えた。
マイクロサービスの作成には「Spring Boot」と「Swagger」を組み合わせた。セキュリティインシデントの状況などから「さすがにもうStrutsは避けたい」と考えた石田氏は、数多くのフレームワークを検討した結果、この組み合わせに決めたと語る。
「世の中のトレンド的にもSpring Bootが来ており、スキルを持ったエンジニアが多いことが大きかった。また機能面も、他の候補と比較してなかなか優れていました。そこでSpring Bootに、REST APIを記述するための仕様を組み合わせるといいのではと考えてSwaggerを選びました」
この2つを組み合わせて標準基本構成（テンプレート）を作成。これを継承して、さまざまなマイクロサービスを組み立てていく方針を決めた。石田氏は、「テンプレート化した背景には、開発スキルのポータビリティやメンテナンス性を向上させるねらいがありました」と語る。
またSpring Bootを利用すると、作成したマイクロサービスをKubernetes上にデプロイしていく際、ビルドプロセスにDockerビルドを組み込んで、小さなマイクロサービスを簡単に作成できるといった独自のメリットが得られるという。
