「コンテナ版HULFT」だからこそ選んだベストプラクティスでの構築
菊池氏は新卒でセゾンテクノロジーに入社し現在4年目のエンジニア。Go言語やAWSを利用して、HULFTのContainer版「HULFT10 for Container Services」の開発に従事している。
伊藤氏の解説にもあったように、HULFTのクラウドネイティブ化の選択肢は2つあった。1つがベンダーのサービスをフル活用するパターン。もう1つが、コンテナオーケストレーションに対応するパターンだ。ベンダーのサービスをフル活用するパターンは、短期間で構築できる、サポートを集約できるというメリットはあるが、移植性が低い、機能がベンダーごとに異なるというデメリットがある。一方、コンテナオーケストレーションに対応するパターンは、ベンダーサービスをフル活用する場合とまったく逆で、移植性が高い、機能が共通というメリットはあるが、開発が比較的複雑、サポートが分散するというデメリットがある。この2つの選択肢から菊池氏たちが選んだのは、後者だった。「HULFTは先ほども紹介したとおり、いろんなプラットフォーム、同じ機能で互いに通信できることが強み。だから移植性や別プラットフォームでも機能を共通化できることを重視した」（菊池氏）とはいえ「ベンダーロックが悪いわけではない。目的に合わせてやり方を選ぶこと」と菊池氏は補足した。
伊藤氏が「判断が難しい」と語っていたベストプラクティスの付き合い方についても菊池氏は言及。「ベストプラクティスへの対応の選択肢も大きく2つある」という。一つは既存のものをそのまま移行した後にベストプラクティスに寄せていくパターン。短期間で移行ができ、これまでの機能がそのまま使えるというメリットがある反面、技術的負債を残すことになり、またベストプラクティスへの対応要望にタイムリーに応えることができない。
もう1つはMVP（顧客に価値を提供できる最小限のプロダクト）に限定してベストプラクティスで再構築し、優先度の高い機能を過去の資産から移植していくパターン。「ベストプラクティスに沿った設計が出来るのが大きなメリット」と菊池氏。加えて、柔軟な方向転換も可能な一方、移行が長期間となり、機能が足りない場合があるなどのデメリットがある。
この2つの付き合い方のうち、菊池氏たちは後者を選択。先述したように必ずしもベストプラクティスに対応する必要はない。しかし、菊池氏たちが移行時にベストプラクティスに寄せることにこだわったのは、移行先のサービスとの兼ね合いが悪くなり、恩恵があまり受けられなくなるためだった。またオンプレミス向けにつくられたシステムやプロダクトを後からベストプラクティスに移行しようとすると、オンプレミス向けの仕様に引っ張られて変えにくいため、技術的負債になってしまう。
続いて菊池氏はコンテナ設計におけるベストプラクティスの例を紹介。オンプレミス版のHULFTはマルチプロセスかつシングルスレッドで動作していた。これをコンテナ版ではシングルプロセスかつマルチスレッドに作り変えたという。「コンテナオーケストレーションの周辺サービスがシングルプロセスにつくられているため」と菊池氏はその理由を述べる。例えばコンテナ内でマルチプロセスが動作していると、子プロセスが何らかの理由で落ちた場合に、コンテナオーケストレーションで死活監視ができなくなる。親コンテナの作り込みをせず、コンテナオーケストレーションの機能を活用するには、シングルプロセスかつマルチスレッドに再構築する必要があったのである。
さらに菊池氏はMVPで再構築して方向転換の余地を残す理由についても解説。クラウドでは日ごとに新技術、新サービスが出てくる。またそれに紐付くユーザーの要望も次々に変わって行く。つまり方向転換の余地を残す背景は、このリリース速度に適応するためだった。
菊池氏が紹介したベストプラクティスとの付き合い方は、レガシーな技術を含み、社内システムをクラウドに移行する場合にも当てはめることができるという。
