コンテナ化分散型マイクロサービスアーキテクチャーへの移行を検討している。しかし、移行の過程で、既存のコードをすべて無駄にしたくはない。そう考えるIT担当者の方に、移行前のヒントをご紹介します。

多くのIT組織が、大規模でモノリシックな既存アプリケーションを、コンテナ化マイクロサービスに分割し、分散型アーキテクチャーで稼働させることに関心を寄せています。これを実現する技術として、DockerとKubernetesが特によく知られていますが、コンテナ化の普及が進むにつれ、その他の技術も急成長しています。多くの担当者がこうした移行にすぐにでも着手しようとするはずです。
これを、デジタルトランスフォーメーションプロジェクトの一環として行うもっともな理由が数多くあります。「チームの生産性の向上から、容易な自動テスト、迅速で柔軟な展開モデル、全体的な柔軟性の向上まで、さまざまなメリットを得られます」。そう語るのは、Gravitational社のCEO兼共同創設者、Ev Kontsevoy氏です。同社は、オープンソースのGravityプロジェクトを立ち上げました。このプロジェクトにより、複雑なクラウドアプリケーションを1つのKubernetesファイルにパッケージ化できます。
しかし、移行には思いがけない落とし穴もあると、Kontsevoy氏は語ります。たとえば「慎重な計画と、R&Dへの高額な先行投資が必要になります」。また、Clouductivity社の創設者であるMarcus Bastian氏も、こう述べています。「モノリシック型アプリケーションを仮想マシンまたは物理サーバーからDocker (またはその他のコンテナ化プラットフォーム) に移行するのは簡単な作業ではありません。アプリケーションをそのまま移すだけでは済まないことが多いのです」。
私たちは、開発者やIT運用の担当者がマイクロサービスに移行するためのアドバイスを、何人かの専門技術者に求めました。彼らは、モノリシック型アプリケーションを最新のマイクロサービスアーキテクチャーに移行した経験を持っています。次の9つのヒントが、移行プロセスに着手する際のガイドとして役立ちます。

 

1. 移行について、関係者全員が同じ認識を持つ

プログラミングを始める前に、プロジェクトに関わる誰もが、プロジェクトの範囲を完全に認識していることを確認します。コンテナ化マイクロサービスアーキテクチャーへの移行に何が必要かを意識していない関係者もいます。この移行を強く求めている意思決定者が、顧客であれ上司であれ、その移行の意味を理解しているかどうかを確認しましょう。特に、こうした種類のアーキテクチャーがDevOpsに密接に関連していることからも、そうした理解が必要になります。DevOpsは今や、十分に理解しないままトレンドを追いかけたり、利用したりする人たちが関心を寄せるほど、よく知られた哲学です。
「重要なのは、HPEが何を実現しようとしているのかを、お客様に正確に説明することです」と、Miguel Murilloは語ります。Miguelは、HPEのソリューション設計者を務めており、最近、eIUMのコンテナ化アーキテクチャーへの移行を支援しました。「たとえば、新しい技術についての知識をお持ちでも、その技術要件を認識していないお客様もいらっしゃいます。VMwareを所有し、コンテナ化に関心のあるお客様が、そのために必要なインフラストラクチャの変更を理解していないこともあるのです」。
場合によっては、根本から議論して、何が期待できるのかを適切に把握しなければなりません。Miguelはこう語ります。「マイクロサービスの捉え方は、お客様によってさまざまのようです。ですから、HPEがなぜマイクロサービス化に取り組むのか、それをどのようにHPEのアプリケーションに実装するのかを、説明する必要があります。お客様は、「規模が大きすぎるので、マイクロサービス化には躊躇します」とおっしゃるかもしれません。マイクロサービスとは非常に小さなコンポーネントであると考えているからです。しかし、それが当てはまらない場合もあります」。

 

2. ダウンストリームに及ぼす影響を特定する

徹底的に顧客の立場に立って、ものごとを把握しましょう。どのような顧客に対してもそれを貫きます。こうした種類の移行では、多数のユーザーが利用している、重要と思われる大規模なアプリケーションに影響が及びます。このため、アーキテクチャーが持つ理論上の洗練さがある程度失われても、そうしたユーザーのニーズに特別な注意を払う必要があります。
このアドバイスは、すべての大規模開発プロジェクトに活かすことができます。Galvanize社で企業インストラクターの主任を務めるJeffrey Lent氏は、きわめて旧式のメインフレームERPをマイクロサービスアーキテクチャーに移植するプロジェクトに携わりました。このシステムは、同社で、中核となる財務機能と、顧客関係管理 (CRM) の機能を果たしていました。Lent氏が直面した最も大きな課題の1つは、コールセンターでCRMを使用している人たちのために、ユーザーインターフェイスを継続させることでした。
Lent氏と彼のチームは、これをすぐに達成できると考え、最初はパイロットプロジェクトとして取り組みました。「ユーザーが使用している緑色の画面を、Webベースのフロントエンドに置き換えることから始めました」と同氏は語ります。「ところが、これについて驚くほどの異論があることが分かりました。コールセンターのユーザーの多くが、その緑色の画面に慣れており、操作を体で覚えてさまざまな業務を行っていたのです。私たちは、そのCICSのインターフェイスに似たショートカットを使用するWebアプリケーションを開発して、以前の使いやすさを維持する必要がありました」。
Lent氏は、最後にこう述べました。「ユーザーエクスペリエンスについては、顧客の声に十分に耳を傾ける必要があります。対象を憶測で捉えないようにしなければなりません。それを、今回のプロジェクトで学びました」。
開発は、外部のエンドユーザーのためだけに行うのではありません。内部のユーザーへの影響も考慮しましょう。「私は、自身の経験から、外部の開発者やQAチームの観点でものごとを考えていました」と、Datawire社の製品設計者であるDaniel Bryant氏は語ります。こうした外部ユーザーは、移行後にリモートのコンテナーオーケストレーションクラスターに展開されるシステムで、部分的なテストと作業を行う必要があります。「新たに移行したシステムは、以前のモノリシック型システムよりも多くの移動可能な要素で構成されています。そうしたシステムや、混合型のコンテナーのような新しい技術では、開発者体験が全体的に変わる可能性があります」。
同氏はこう続けます。「CNCFがホストするTelepresenceアプリケーションは、リモートとローカルとの間で開発を行う際に役立ちます。プロキシを使用してテストすると、ノートパソコンからクラスター環境に仮想的にアクセス可能です。同時に、すべてのローカルツールを引き続き利用できます。これにより迅速なフィードバックを行えます。

 

3. 外側から内側の観点で移行を進める

手に負えないモノリシック型アプリケーションを完全に分割してマイクロサービス化すれば、個々のサービスが効果的に連携できる、と夢見ても、それが常に現実的であるとは限りません。「アプリケーションをDockerに移行しただけで正常稼働。そのような幸運に恵まれることは滅多にありません」とClouductivity社のBastian氏は指摘します。「場合によっては、時間をかけて、モノリシック型アプリケーションを、Dockerで構築した個別のマイクロサービスに分割する必要があります」。
Bryant氏は、モノリシック型からマイクロサービスへの移行プロジェクトをいくつか経験しており、そこで得られた教訓についてこう話します。「「外側から内側」への観点を持つことです。外部ユーザーとそれに関連する機能の観点から、最初の移行段階を推進します。そうすることで、目に見える (かつ実証可能な) エンドツーエンドの価値を、はるかに簡単に創出できるからです。たとえば、ニュースレターのサインアップを行える従属的なマイクロサービスを新たに追加すれば、「モノリシック型システムからユーザーサブシステムを抽出」するよりも、プロジェクトに明確な境界を持たせることができます。このアプローチによって、「内部」システムのリファクタリングに伴う技術面の煩わしさを軽減できます」。
Lent氏がプロジェクトで目標にしたのは、「CRMサービスから中核となる財務システムに至るまで、ERPからできるだけ多くの機能を取り除いていくことでした」。前述のように、同氏のチームはまず、ユーザーインターフェイスの移行に着手しました。「それを無事終えた後、フロントエンドとメインフレームを橋渡しするコードを、メインフレームの機能を果たす実際のマイクロサービスに置き換えました」と同氏は語ります。
ITの一部のグループは、中核となる財務システムの移植は達成可能だと考えていました。「しかし、私たちの多くは、かなりの傲慢さを感じていました。大手公開会社のコンプライアンス要件の評価や、順守の複雑さに、市販のソフトウェアで対応できると考えるほどでしたから」とLent氏は振り返ります。「私は、すべてのリファクタリングが終わる前にプロジェクトを離れました。CRMの機能とEDIに関する数多くのサービスを、マイクロサービスアーキテクチャーにリファクタリングできましたが、その財務システムは今でもメインフレームで稼働しています」。

 

4. ジョブに適した言語を選択する

モノリシック型アプリケーションは、一般に1つの言語またはプラットフォームで構築されますが、マイクロサービスベースのアーキテクチャーでは、必ずしもそうとは限りません。それをお勧めできないことさえあります。「モノリシック型アプリケーションを分割するときには、すべてのコンポーネントのコードを同じ言語で書く必要はありません」と、Solodev社のCTO兼創設者のShawn Moore氏は語ります。「クラウドでは、アプリケーションに最適な言語を選択します。たとえば、従来のPHPまたは.NETアプリケーションをAWS Lambdaの関数に変換中だとします。LambdaはPHPをサポートしていますが、Pythonなどの言語を使用するとよいでしょう。そもそもPythonは、Lambdaを開発するために設計されました。多数のコードサンプルや詳細なドキュメントがあり、大規模なユーザーベースを確立しています」。
「それに、Pythonでコードを書くのは本当に楽しいのです」とMoore氏は付け加えました。

 

5. データの保存先に目を向ける

「モノリシック型アプリケーションの多くに、状態情報の保存にローカルディスクを使用するコードが含まれています。また、こうしたアプリケーションは、設定を、環境変数などではなくファイルから取得する場合もあります」とBastian氏は語ります。マイクロサービスアーキテクチャーへの移行で変更すべき点を検討する際には、この観点が重要になります。
Bastian氏はこう続けます。「アプリケーションのインスタンスは、それに関連する一次データとともに、いつでも消える可能性があると考えましょう。たとえば、実装しているオーケストレーションプラットフォームのDockerスケジューラが、コンテナーを、クラスター内の別のホストに移動する判断を行っている場合、セッションデータを、RedisやMemcache、またはその他のキャッシュソリューションに移動することを検討します。これにより、すべてのコンテナーが、別のサービスを通じて、状態情報を利用および共有できます。データの耐障害性が高まるという大きな特典も得られます」。
Belitsoft社のDevOpsエンジニアであるArtem Aksenkin氏は、セッションデータに限らず、すべての種類のストレージを、アプリケーションがどのように扱うかを再考した方がよい、とアドバイスします。「Dockerを使用する場合、マイクロサービスとデータベースを1つのイメージに納めないようにします。2つのファイルで、2つのイメージを個別に作成します。Dockerは軽量であるため、大きめに構成すると、そのメリットが失われてしまいます」。
これには、多少の作業があらかじめ必要になりますが、さほど煩わしいことではなく、長い目で見れば、マイクロサービスアーキテクチャーのメリットの1つである柔軟性が得られると、Gravitational社のKontsevoy氏は指摘します。「CPUの性能とストレージがさらに必要になると、こうしたリソースの拡張によって生じるコストと特性に、非常に差が出ることが分かります。ローカルストレージに最初から依存しないようにすれば、将来のワークロードへの適応が比較的容易になります」。

 

6. APIに常に注目する

マイクロサービスアーキテクチャーでは、さまざまなコンポーネントが、外部と接するAPIを介して通信しています。アプリケーションでは、こうしたAPIが重要な役割を果たします。モノリシック型システムを分割する際には、数多くのAPIをゼロから書くことになるため、適切に書く必要があります。
「マイクロサービスが、お互いのAPIを使用して相互通信する場合、下位互換性を維持できるスキーマを設計することが重要です」とKontsevoy氏は語ります。「コードを更新する方法として、他の開発者全員に、マイクロサービスの最新バージョンを展開することだけを求めてはなりません。これでは、モノリシック型アプローチに一歩後戻りすることになるからです」。
同氏はこう続けます。「開発チームは、古いAPIを永久にサポートすることと、今後も開発を加速することとの間で合理的に妥協し、それに同意しなければなりません。これは、そうしたAPIの設計が重要なスキルになることも意味しています。APIの変更を頻繁に中断することは、複雑なマイクロサービス開発で、チームが生産的になれない原因の1つになっています」。
こうした状況で 役に立つツールがあります。NetEnrich社のCTO、Javed Sikander氏は、Azure API ManagementやApigeeなどのAPI管理ツールを、マイクロサービスAPIのセキュリティ、スロットリング、エラー処理に利用することを推奨しています。

 

7. 非同期の機能を採り入れる

Kontsevoy氏は、従来のソフトウェアエンジニアリングのアプローチをこう説明しています。「お互いを呼び出すサブルーチンやオブジェクトを追加することで、アプリケーションを徐々に構築する必要があります。しかし、ワークロードが拡大し、アプリケーションそのものを複数のマシン、あるいはデータセンターに拡張しなければならなくなると、そうした構築方法では対応できません」。
この複雑さが、分散型マイクロサービスに移行する主なきっかけの1つになります。このためには、イベント主導型モデルを中心に据えて、アプリケーションを再設計する必要があります。このモデルでは、関数の呼び出しと、その結果待ちを同期的に行わず、イベント送信後に、結果を待たないという手法を採ります。
これを行う重要なツールの1つがメッセージバスです。「モノリシック型アプリケーションをイベントハンドラーとイベントエミッタに分割すると、堅牢で性能の良い、柔軟なメッセージバスが必要になります」とKontsevoy氏は述べます。アプリケーションの規模と複雑さに応じて、多数の選択肢からメッセージバスを選択できます。「単純なユースケースとして、Redisなどの利用があります。幅広い選択肢で、その反対側に位置するのが、Kafkaのようなストリーミングパイプラインから、インフラストラクチャや監視に至るまで、複数のイベントソースからのイベントを処理する機能です。アプリケーションを本格的にクラウドネイティブにして、それ自体でのスケールアップとスケールダウンを可能にする必要がある場合、そうした機能を選択できます」。

 

8. 可能な限り自動化する

自動化は、DevOps全体を通して重要であり、レガシーなモノリシック型システムをマイクロサービス化するときに不可欠です。
「可能な限り自動化しましょう」と、ScienceSoft社でJava設計者を務めるVladimir Sinkevich氏はアドバイスします。「アプリケーションを複数のコンポーネントに分割すると、それぞれにテスト、展開、プロセスの更新を伴う多数のマイクロサービスが存在することになります。これらのプロセスすべてを個別に追跡する必要があります。テストとCI/CDの実践を自動化できれば、分散型アプリケーションの開発、テスト、展開を大幅に効率化できます」

 

9. 状況によっては、移行ではなく再構築する

Trulia社のゼネラルマネージャ、Tim Correia氏は、最近、大規模なプロジェクトの再設計を監督しました。その再設計では、企業の機能の大部分を、マイクロサービスアーキテクチャーに移行する必要がありました。それから得た教訓は、状況によっては、ゼロから構築するのが最善だということでした。
「移行より再構築の方が最良の解決策になることもあります。そうすることで、パフォーマンスと速さの可能性を最大限に高められます」とCorreia氏は語ります。「当初、既存のプロセスをマイクロサービスに移行しようとしましたが、それには非常に無理があることに気が付きました。一歩下がって全体を眺め、各サービスの現在の設計を再評価することが最適なアプローチであると判断したのです。最初に時間がかかりましたが、最終的な製品では、技術的負債を除去して、コストを低減し、リソースを節約できました」。
成果につながる準備
移行作業に気後れしそうになったら、こうしたヒントが、最初のステップの手助けになります。大きな困難にぶつかることになっても、この記事で取材した人の誰もが、その取り組みを価値あるものと認めるでしょう。
HPEのMiguel Murilloは、顧客のサイトで使いやすさが向上したことで、その価値を実証できたと感じています。eIUMは、当初OpenStackをベースに構築されましたが、OpenStackを初期に採用した人でさえ、コンテナ化を勧めています。「実は、コンテナーの方がよりシンプルなので、コンテナー管理のトレーニングは1週間で完了できます。同じことをOpenStackで行うには、1か月が必要です。OpenStackは多数のサーバーで管理する必要がありますが、コンテナーは自分のノートパソコンで管理できます」。

_{この記事/コンテンツは、記載されている個人の著者が執筆したものであり、必ずしもヒューレット・パッカード エンタープライズの見解を反映しているわけではありません。}