パーソルキャリアの吉元裕人氏

　ミイダスは社内の事業創出制度からスタートし、低コスト、スピード重視で機能を実装したという。アプリケーションエンジニアがインフラ運用にまで携わることが前提だったため、オンプレミスを検討する余地はなかったそうだ。採用したのは格安な仮想サーバで、当初はコストと効果のバランスも悪くなかったという。しかしデータ量が増加し、処理負荷が高まるにつれてインフラ運用に掛かる手間が課題となった。毎月幾つもの仮想マシンのデータ容量を拡張し、処理時間が延び続けるバックアップ作業やバッチ処理の最適化を繰り返したが、CPUとメモリ利用率は常に高い状況にあった。

AWS移行前のシステム構成

　AWS移行前のミイダスのシステム（写真1）には2つの課題があったという。1つはサーバを機能ごとに整理していなかったことだ。パーソルキャリアは、ベースとなる仮想サーバをコピーしてサーバを増やせるようにと、全ての機能をサーバに実装していた。そのため「同じ機能が別のサーバでも動いているといったリソースの無駄が発生しており、構成をもっとシンプルにする必要がありました」と同氏は説明する。もう1つは、サーバのスケールアップやスケールアウトのオペレーションに時間を取られてしまうことだ。「毎月のように幾つもサーバを増やしたり、データ容量を拡張したりしており、サービス維持だけのために多くの時間を取られていました」（吉元氏）

　これらを解決するために同社は、スケーリング（リソースの増減）を含めた運用コストの低いインフラ基盤への移行を検討した。移行プロジェクトのスタートは2017年8月。関わったインフラエンジニアはわずか3人で、しかも他の役割を兼任しながらのプロジェクトだった。

写真1　AWS移行前のシステム構成《クリックで拡大》

ソリューションアーキテクトの力を活用しつつ基本構成を決定

　日々の運用負荷を削減するために、仮想サーバからクラウド基盤へ移行するのが基本的な方針だった。クラウドサービス選定においてはAWSの他に「Google Cloud Platform」（GCP）も候補に挙がり、カタログスペックに基づいてコスト試算をしてみたところ、大きな違いはなかったという。そこで注目したのが、サービスの充実度だった。

　「構成をシンプルにするためにも、運用コストを削減するためにも、各種サービスの活用は大きな効果が期待できます」と吉元氏は語る。AWSを選んだのは、実際にミイダスで使いたいサービスがどれくらいあるかを比較した結果からだったという。

　他にも幾つか細かいポイントで、AWSが優位だったと吉元氏は付け加える。例えば、社内の別サービスでAWSを既に使っている実績があったこと、基幹システムをAWSに移行する予定があり、全社でサポートサービスの「ビジネスサポートプラン」を契約済みだったことなどだ。

　吉元氏はテスト環境を作って懸念点を解決し、改良したテスト環境を作り直してチェックした。「作っては壊しを繰り返し、構成がある程度まとまったところで資料を作成して、AWSの『ソリューションアーキテクト』にレビューしてもらいました」。ここで、ビジネスサポートプランが役立ったという。

　AWSのソリューションアーキテクトは、顧客のコスト負担、オペレーション負担を最小限に押さえるためのアドバイスをしてくれる認定資格者だ。2018年10月にオープンしたスタートアップ企業向け支援施設「AWS Loft Tokyo」にも、ソリューションアーキテクトが常駐している。「これからAWS利用を考える企業のサポートとして利用できるのではないか」と吉元氏は期待を語る。

AWS移行後、現在のシステム構成

　ソリューションアーキテクトの力を借りつつ作り上げた設計の基本方針は、既存アプリケーションにできるだけ手を入れず、改修を最小限に抑えることだった。その後も週に1回の定期的なリリースを続け、開発スピードを落とさないことと、可能な限りAWSのサービスを使い、システム全体の構成をシンプルにすることを目指したという。「コストを抑えられるのはクラウドの魅力の一つですが、今回のインフラ移行は今後の成長を支えるための施策であり、コスト削減を追究し過ぎないというのも、基本的な方針に取り入れました」（吉元氏）

Amazon ECSが運用現場にもたらした効果

　実際の構築作業は2017年10月から12月に進め、2018年1月には本番環境をAWSへ移行した（写真2）。構成検討に2カ月、開発に3カ月というスピード感あるプロジェクトだった。本番環境移行には半日以上を要したが、そのほとんどはデータベース移行にかかった時間だという。こうしたスピードを実現できたのは、当初の計画通りAWSサービスを多用し、自社で機能を作り込んで実装する部分を減らした成果でもある。その中でも大きな効果を挙げたのがAmazon ECSだと吉元氏は言う。

写真2　AWS移行後のシステム構成《クリックで拡大》

　吉元氏は「できるだけアプリケーションに手を入れたくなかった」ので、仮想サーバをそのまま「Amazon Elastic Compute Cloud」（Amazon EC2）に移行しようと考えていたという。一方でAmazon ECSなら、コンテナ管理ツール「Docker」のOS／アプリケーションイメージ（Dockerイメージ）を管理するだけでよいので、Amazon EC2よりも構成がシンプルになり、依存関係も気にせずに済む。開発用の「Mac」でDockerを利用していたので、設定を流用して、開発環境から本番環境まで動作環境を統一することもできた。

サーバ、ソフトウェアをコンテナ化し、運用を自動化するAmazon ECS

　依存関係を気にせずに、使いたい機能をコンテナとして採用できるのは、スタッフの予想以上に開発スピード向上に寄与したという。従来なら自分でビルドしてサーバに組み込まなければならなかったミドルウェアも、コンテナとして手軽に導入できる。公式のDockerイメージを使えば自身でビルドする必要はないし、ミドルウェア同士の依存関係を考える必要もない。便利だがくせのあるミドルウェアも、ためらいなく採用できたそうだ。

　運用が始まれば大きな効果をもたらすAmazon ECSだが「環境構築には慣れが必要だなと感じました」と吉元氏は明かす。細かい設定はリソース構築自動化ツール「AWS CloudFormation」で管理するため、まずCloudFormation自体への慣れが必要になる。「設定箇所が多く、『サービス』『タスク』といったCloudFormationの概念にもなじんでいく必要がありました。デプロイの手順もこれまでとは変わりました」

　仮想サーバで運営していた当時は、新機能を組み込んだ新しいソースコードを、UNIXのファイル転送ユーティリティー「rsync」でコピーしてデプロイしていた。Amazon ECSを使うためには、新しい機能を実装したDockerイメージをビルドし、アップロードしなければならない。こうしたデプロイの手間を打ち消すに十分なほど、運用管理は楽になったようだ。コンテナ単位で管理すればいいので、その負担の少なさは仮想サーバで管理していたときとは比べものにならないという。ヘルスチェックもスケーリングもAmazon ECSにお任せで済むからだ。

　「できるだけアプリケーションを変更しない」という基本方針のため、パーソルキャリアはAmazon EC2インスタンスも使っている。ただし以前は16台あった仮想サーバを、10台のAmazon EC2インスタンスにまとめ、管理対象を減らしたという。「インフラ由来のアラートも明らかに減っています。コンテナ内でトラブルがあっても自動的に立ち上げ直してくれるAmazon ECSの効果は大きい」と吉元氏は語る。

　運用にかかるオペレーション負担は明らかに減少したが、費用面では以前より高コストになったと吉元氏は指摘する。これは当初から掲げている通り、コスト削減よりもオペレーション負担削減や開発スピード維持を優先するという目標通りだ。役割を分割してAWSのサービスを多用した上に、可用性を高めるために「Multi-AZ配置」を採用した。わずかな費用アップでこれだけの高い効果を得られたことを、社内でも評価されているという。

　「Amazon ECSをはじめとするAWSサービスで構築した新環境は容易にスケールでき、今後の成長にも安心して対応できます。手の掛かるサービス維持作業が減り、開発に集中できる環境も整いました。全体的に見て、大満足です」（吉元氏）

　吉元氏は講演で、プロジェクトの成果についてそう語った。そして「これからも成長するサービスを支えるインフラをAWSの機能を活用して構築したい」と締めくくった。