レガシーシステムは顧客のニーズがあるからこそ生き残っている
本セッションでは、増井氏が取り組んださまざまな施策のうち「新しいサービスのキャッチアップ」「既存の機能をクラウドに置き換えても担保する必要があること」という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マウントの機能が追加されることを発表初日に知り、即座に検証。この機能を用いることで適切なアーキテクチャを構築できることを発見したのだ。
セッション終盤、増井氏はレガシーアプリケーションの開発・運用に携わる意義を述べる。古いアプリケーションとは、裏を返せば生き残り続けるだけのニーズがあるということ。24年も開発・運営が続いているということは、多くのユーザーが日々の業務のなかで「COMPANY」を活用していることを意味している。
「『COMPANY』のクラウドネイティブ化に携わる醍醐味は、現在のシェアを生かしつつアプリケーションが持つ可能性をさらに拡大できること」と増井氏は強調する。また、この事例のようにオンプレミスで運用されているアプリケーションはエンタープライズ領域に多数存在しているため、クラウド移行のノウハウは今後さらに重要になっていく。その技術を持ったエンジニアの市場価値も増していくことは間違いない。
最後に増井氏はこう締めくくった。
「挑戦と思って取り組んだプロジェクトですが、いざ困難に出会うと、面倒だな、大変だと思ったりもしました。しかし、エンジニアは難題と向き合った経験が、自分自身にとって貴重な財産になります。他人に語れるような経験を数多くしたことが、そのままエンジニアとしての価値に結びつくはずです」
