20年超の歴史を持つアプリをクラウド化して学んだこと――若きSREの挑戦の足跡【デブスト2020】

【Session2】古の大企業向けパッケージソフトのクラウド移行にJoinして見えた面白さ

　株式会社Works Human Intelligenceが提供する人事給与ERPパッケージシステム「COMPANY」は20年以上の歴史を持つアプリケーションだ。大手1100企業グループが利用しており、HRのシステム市場においてシェアNo.1を獲得している。同社の増井秀和氏は、AWSの知見を生かして「COMPANY」のクラウドインフラ改善や開発、IaC（Infrastructure as Code）化に注力しており、かつ開発チームのメンバーとしてオンプレミスアプリケーションのクラウドネイティブ化を行っている人物だ。本セッションでは増井氏が、自身の経験を通じて得た知見について共有した。

株式会社Works Human Intelligence Product Div. SRE Dept. Cloud Architecture Grp. Cloud Engineering Senior Candidate 増井秀和氏

クラウド移行により運用の課題を解決する

　「COMPANY」は1996年に誕生し、（登壇時点で）24年目を迎えた歴史あるアプリケーションだ。日本の大手法人の人事関連業務をサポートするため、多種多様な顧客のニーズに対応できるように幅広い機能をそろえている。オンプレミスのサーバー向けに開発されたアプリケーションだが、新しいバージョンではAWSを用いたクラウドサービスとしての提供も行っている。

　一方で、歴史があるということはシステムにおいて技術的負債が蓄積されていることも意味する。用いられている技術はレガシーであり、かつ膨大なコード量と各機能同士の密結合が存在している。具体例を挙げると、プログラムはJava6で書かれておりコード行数は320万以上。1～2年前まではビルドに約4時間もかかっていた。

　クラウドサービスとしての提供にも多くの課題がある。例えば、新機能を顧客に提供する前にはPreparationという業務が必要になっている。これは、リリース作業後に社内のメンバーがデプロイの正常終了やアプリケーションの正常動作などを確認するための工程だ。この作業にかかる工数は非常に大きい。さらにAWSを用いてはいるが、Amazon EC2によるホスティングが多く、クラウドによるメリットを十分に発揮できてはいない。

　「これらの課題を解決するため、Works Human Intelligenceは『COMPANY』をクラウド移行するプロジェクトを推進しています。私はこのプロジェクトに参画し、人事・給与関連の処理を担うAmazon EC2のバッチサーバーをAmazon ECS化していく役割を担いました。」と増井氏は述べる。

増井氏が携わった移行プロジェクトのアーキテクチャ概要。矢印で示された部分が対応箇所だ。

　Amazon ECS化の理由は、以下の問題点を解決するためだ。

• 高負荷でメモリなどが枯渇することがある
• 負荷への対策がスケールアップしかない（そのためダウンタイムを伴う）
• 稼働状況によらず一定のコストがかかる（バッチインスタンスのサイズはm5.large ～ m5.2xlarge程度）

　増井氏が本プロジェクトに参画した理由は3つある。1つ目はAWSについて学んできた経験をアプリケーションに生かすため。増井氏は過去にAWS Solution Architect Professionalの資格を取得しており、その知識をプロジェクトで試したいと考えた。2つ目はAmazon ECSに触れることで、コンテナ技術という新しいスキル・知見を得るため。3つ目は、今後のプロダクトの発展に貢献できるような影響力のある仕事をしたいと考えたためだという。

レガシーシステムは顧客のニーズがあるからこそ生き残っている

　本セッションでは、増井氏が取り組んださまざまな施策のうち「新しいサービスのキャッチアップ」「既存の機能をクラウドに置き換えても担保する必要があること」という2つの軸に沿って解説した。

　まずは「新しいサービスのキャッチアップ」について。これまでAWSについて学んできたとはいえど、プロジェクトでAmazon ECSという新しいサービスを扱う以上、情報のキャッチアップは必須である。インプット習慣を仕組み化するため、増井氏はSlackのRSSアプリを活用した。Amazon ECS関連のブログ記事や機能追加の情報があればRSS経由でSlackに通知されるようにし、入手した情報はすぐに自ら手を動かして試したという。

　次に「既存の機能をクラウドに置き換えても担保する必要があること」について。移行対象のバッチには、実行中のログをアプリケーションからダウンロードできる機能がある。

　だがAmazon ECSの場合、ログはAmazon CloudWatch Logsにアップロードされる。そのため、同等の機能を移行後のアーキテクチャでも実現するならば工夫をこらさねばならない。

　増井氏はいくつかの案を考えた。1つ目の案は、Amazon Cloudwatch LogsのAmazon S3へのエクスポート機能を使うこと。だが、この機能はバッチ的な実行であるためリアルタイムでログ情報を取得することは不可能だ。

　2つ目の案はAmazon Kinesis Data Firehoseを用いてストリーミング処理でAmazon S3にログを転送すること。だが、Amazon Kinesis Data Firehoseを用いると金銭的コストが増加してしまう。さらに、既存のアーキテクチャと同じログ形式にする場合、AWS Lambdaによるログ整形処理が必要になるためシステム構成が複雑になることがわかったという。

　3つ目の案はサイドカーのfluentdコンテナを立ち上げてログをAmazon S3へと転送すること。だが起動コンテナが増えると必要な金銭的コストも増加するため、このアーキテクチャも避けたい。

　どの案もうまくいかないため増井氏は悩んだ。だが、このときに前述のキャッチアップの習慣がいきたという。AWSサポートへの問い合わせやRSSでの情報のインプットなどを行う過程で、AWS FargateへのAmazon EFSマウントの機能が追加されることを発表初日に知り、即座に検証。この機能を用いることで適切なアーキテクチャを構築できることを発見したのだ。

増井氏の提案したアーキテクチャ。AWS FargateにAmazon EFSをマウントすることで、ログをAmazon EFSへと出力可能にした。

　セッション終盤、増井氏はレガシーアプリケーションの開発・運用に携わる意義を述べる。古いアプリケーションとは、裏を返せば生き残り続けるだけのニーズがあるということ。24年も開発・運営が続いているということは、多くのユーザーが日々の業務のなかで「COMPANY」を活用していることを意味している。

　「『COMPANY』のクラウドネイティブ化に携わる醍醐味は、現在のシェアを生かしつつアプリケーションが持つ可能性をさらに拡大できること」と増井氏は強調する。また、この事例のようにオンプレミスで運用されているアプリケーションはエンタープライズ領域に多数存在しているため、クラウド移行のノウハウは今後さらに重要になっていく。その技術を持ったエンジニアの市場価値も増していくことは間違いない。

　最後に増井氏はこう締めくくった。

　「挑戦と思って取り組んだプロジェクトですが、いざ困難に出会うと、面倒だな、大変だと思ったりもしました。しかし、エンジニアは難題と向き合った経験が、自分自身にとって貴重な財産になります。他人に語れるような経験を数多くしたことが、そのままエンジニアとしての価値に結びつくはずです」