※ 本記事に記載の情報は、講演当時の内容です。現在とはサービス内容などが異なる場合があります。
30年の資産をSaaSへ、データ連携の「次」を担うHULFT Square
セゾンテクノロジーは1970年 9月に設立（当時の商号は株式会社西武情報センター）。1992年4月に株式会社セゾン情報システムズへ、2024年4月に現在の株式会社セゾンテクノロジーへと商号を変更した。金融や流通業界などのシステム構築を請け負うSI事業と、「HULFT（ハルフト）」やDataSpiderなどのプロダクトを提供するHULFT事業の2つの事業を展開してきたITサービスプロバイダである。
主要プロダクトの一つである「HULFT」はシステム間連携、ファイル連携用のミドルウェア。HULFTは販売開始してから30年が経過し、今では銀行や自動車メーカーなどで業界のデファクトスタンダードとして活用されている。長年、ファイル連携やデータ連携の知見を積み重ねてきたことで、昨今はその積み重ねた知見を生かして、「お客さまのDXの実現をサポートする事業を展開している」と畑氏は話す。
現在はHULFTの他、ノンコードによるデータ連携ツール「DataSpider Servista」、散在するメタデータを収集・整理・カタログ化する「HULFT DataCatalog」などの主要プロダクトを提供している。それらのデータ連携技術で培った基盤と知見を活かし、昨年リリースされたのが「HULFT Square」だ。
HULFT SquareはSaaSやオンプレミス、マルチクラウドに分散して管理されるさまざまなデータを一元的に管理・連携し、ビジネスに素早く生かすことができるデータ連携プラットフォームである。
それを可能にしているのが、HULFT SquareのHULFTの転送機能である。「1年以上かけて連携に必要なHULFTの機能のみを実装し、リリースした。どう拡張して、どのようにお客さまに展開していったのかを解説したい」と畑氏は語る。
なぜHULFT Squareは高速で機能拡張できたのか？
このような機能を開発した背景にあったのが、「HULFTが持っている機能を使いたいというお客さまからの要望が増えてきたため」と畑氏は話す。HULFT SquareとHULFTの機能を比較すると、HULFTではできることがHULFT Squareでは制限されていることが多くあったからだ。
だが、HULFT Square転送機能を拡張するにはいくつかの課題があった。第1は開発の難易度が高く、開発工数も膨大になること。なぜなら、転送機能はHULFT Squareとは異なる開発言語や環境で開発されていた。また30年にわたって拡張し続けた詳細機能もあり、それを一つひとつ、コードを書いて拡張していくのは膨大な時間とコストがかかる。さらにHULFTとHULFT Squareではデザインのコンセプトが異なっていた。「GUIのデザインや用語を一から定義する必要があった」と畑氏は語る。
第2に十分なテストが必要になること。HULFTは銀行などの金融業界で使われているため、高い品質が求められる。
求められる機能ごとにコードを追加して、拡張し続けるのは想像以上に時間がかかる。そこで「お客さまがHULFT Squareで何をしたいのか、原点を振り返ってみた」と畑氏は話す。お客さまの希望は、HULFT SquareでHULFTがそのまま使えるようになること。そこで畑氏たちはHULFTをそのままHULFT Squareで提供できるようにすればよいと考えたのである。
検討を重ねた結果、HULFT Squareのユーザー管理やストレージとは別の場所にユーザーごとの実行環境を作成し、そこでコンテナを起動させてHULFTを動かせればうまくいくのではと考え、開発を進めていった。
とはいえ、「ただコンテナでHULFTを動かしているだけでは、HULFT SquareでHULFTの機能を提供したとは言えず、意味がないことが分かった。そこで少し工夫をした」と畑氏。それがコンテナイメージでパッケージ化するという方法である。具体的にはコンテナイメージ内にベースイメージを設け、そこにHULFT Squareと連携する機能を改良して実装したのである。「こうすることでHULFTは一切変更を加えることなく、HULFT Squareのユーザー管理やストレージを使えるようになると考えた」（畑氏）
この仕組みはHULFT以外にも活用できる。「サードパーティの他のプロダクトやHULFT Squareの機能を拡張するプログラムなどにも利用できる」と畑氏は言う。
このアーキテクチャを導入したことで、HULFTの詳細な機能の開発は不要になり、HULFT Squareとの統合・結合部分のみの開発、実装だけとなった。またHULFTのコードは一切変更していないため、「HULFTの品質をそのまま担保することにもつながった」と畑氏は言う。
結果、これまではHULFTと連携する一部の機能でさえ1年以上かかっていたのが、「約2カ月でほぼすべての主要な機能が開発できた」と畑氏は語る。
次に考えたのは、ユーザーにタイムリーに提供する方法について。HULFT Squareにはデータ連携処理をアプリケーションとして提供している場所が既にあることを思い出したのである。「このアプリケーションの仕組みを、HULFT Squareの機能を提供するのに使えるのではと考え、アプリケーションを拡張していった」と畑氏は続ける。
こうしてアプリケーションによってプログラムを提供できるようになったことで、複数の効果が得られた。第1に、機能ごとにリリースが可能になったこと。第2に、機能の更新タイミングを任意に選択できるようになったこと。第3に、個別のニーズに合わせて最適なソリューションを提供できるようになったことだ。
今回のHULFT転送機能の開発を通じて、畑氏が得た学びは2つ。一つは既存コードを単に拡張していくという安易な選択肢だけではなく、視点を大きく変えて全体の効率を考えた選択肢も検討すること。もう一つが、開発スピードに応じた、提供スピードの改善も合わせるとより効果的になるということだ。
人中心から自動化中心へのパラダイムシフトを目指すSRE改革
続いてテーマはSRE改革に移り、伊東氏が登壇した。伊東氏はHULFT Squareの開発にも携わっている一方で、SREエンジニアとしても活躍している。
サービス運用では苦労することも多い。例えばリソース管理でよくある苦労として挙げられるのが、本番環境の前のプレ本番環境やテスト用の環境、開発環境など、開発者が手動では把握しきれないほどのさまざまな環境を作ることがある。またデプロイであれば、デプロイ対象の過不足がないかの確認が必要になる。モニタリングでは、メトリクスやログが散在していたり、障害があれば、職人芸と化した障害調査が必要になるなど、「とにかく手と時間がかかっていた」と伊東氏は振り返る。
ここで伊東氏はHULFT Squareで実際にあった苦労話を紹介した。HULFT SquareはEKS（Amazon Elastic Kubernetes Service）を基盤に構築している。Kubernetesにはマニフェストファイル（デプロイ設定のプロファイル）が数多くある。これを環境ごとに管理していたため、設定が微妙にずれてしまうという状態に陥っていた。許容できないずれが分かると、そのたびに差分がないかを目視でチェックしなければならず、1回のデプロイのために1～2日の時間を要していたという。
またデプロイの場面でも、デプロイの結果の確認に不備があり、開発環境のモジュールをプレ本番で使用していたり、デプロイのし忘れなどがあったという。
モニタリングでもプレ本番環境でテストがうまくいかず、原因を探ろうとしてもログが散在していて探れなかった経験もある。設定ファイルを網羅的に確認して、原因がテスト環境の手動変更だと判明したこともあった。
HULFT Squareの運用チームには優秀な先輩、同僚がいる。目立ったミスが多かったわけではないのに、なぜうまくいかなかったのか。伊東氏は「人を中心としたシステム運用になっていたからではないか」と振り返る。
具体的にはAWSコンソールのボタンを人が押してリソースを作成したり、デプロイする際は分厚いデプロイマニュアルを確認し、その通りにCLIを手動で実行していた。「このあたりのマニュアル作業は一見、早くて便利ですが、環境差分が頻繁に発生するようになると、ミスの量が増大。その反省からチェック作業が増えていき、そのうち限界になると思いました」と伊東氏は語る。
そこで、自動化を中心据えることを考え、まずはスモールスタートで実施。すると自動化した部分が安定し、デプロイ速度も上がるなど効果を実感したという。これはまるで、人を中心にシステムが回っていると考える天動説から、自動化を中心に据え、太陽と捉えた地動説にパラダイムシフトしたような経験だった。
自動化を進めるうえで、IaCやCI/CDを中核に位置づけるというのは、具体的にどういうことか。例えば、コードフリーズやQAが完了すると本番環境にデプロイし、問題があればロールバックするといった各工程を「ワンクリックで完了するようなイメージ」と伊東氏は言う。
とにかく人手を介さないよう、ファイル差分、環境差分を自動でチェックするのはもちろん、新しいファイルを追加する場合は、どう自動でチェックするかを考えた上で、ファイル追加を行うようにした。またデプロイを行うのであれば、何がデプロイされるのか、サマリーページに自動集計するようにしたという。
自動化は一朝一夕にはできない。だが、少しずつ「今ではチームの常識が変わり、まず自動化されているかを考えるようになった」と伊東氏は語る。実際、運用上の繰り返し作業（トイル）が減少し、リリースの安定化、リードタイムやデプロイイシューの数が減るなどの具体的な成果につながっていると言う。
最後に伊東氏は会場の参加者に次のように呼びかけ、セッションを締めた。
「天動説の心地よさに浸るのは容易です。今でも油断すると手作業で仕事をしてしまいたくなることもある。ですが、私たちのチームは地動説を選び、歩んでいる。運用で同じような苦労している皆さん、一緒に頑張りましょう」（伊東氏）
