AWS移行及びIaCの導入事例

株式会社エーピーコミュニケーションズでは、数多くのAWS案件を対応させて頂いております。今回は、大手金融機関様でのプライベートクラウドからAWSへの移行をおこなった案件について、ご紹介致します。

移行の背景と課題

プライベートクラウドでシステムを運用していた頃は、以下のような問題が存在していました。 そのためにも、まずは既存の環境をそのままクラウドリフトすることも一つの手段であり、クラウドネイティブな環境に切り替えていくのは、その後、必要に応じて実施するケースも多いです。

全体的に、自分たちのシステムのことを掴み切れないまま恐る恐る運用保守を続けていかなければならない状態であり、ビジネス的にもリスクがあるだけでなく、エンジニアの心理的安全性にも悪影響がある状態となってしまっていました。

そこから導き出された課題が以下でした。

移行の全体像

このシステムはAPI連携のサービスであり、API Gatewayのバックエンドにアプリケーションサーバとデータベースが存在するシンプルな構成でした。移行にあたって特に考慮が必要なのが、以下のリソースの移行でした。

サービスの受け口としてはインターネットから通信を受け付けるシンプルな構成であったため、基盤部分については可用性や冗長性を意識しながら一般的なAWSのベストプラクティスに沿って進めていくことで設計・構築ともに大きく苦労することなく移行ができました。 データベースはVM上でホスティングしていたものをマネージドのAuroraへ移行し、アプリケーションサーバはVM上でホスティングしていたものを、EKS上のコンテナとしてホスティングすることにしました。
データベースについては移行元と移行先でDBエンジンが異なっていたため、その対応がメインでした。独自ツールでの移行が既に決まっていたことから利用しませんでしたが、SCTやDMSを利用した移行手段も存在しますので、そこまで大きなハードルにはならないと思います。 アプリケーションについても、VM上で動かしていたJavaプロセスをそのままコンテナ上で起動するようにしただけなので、特に問題なく移行ができました。
このように特に大きな苦労もなく基盤の管理負担を大幅に軽減することができました。

課題を解決し、新たな問題を生まないためのIaC

基盤構築をIaCで行うことにしましたが、導入してみたものの元々の課題が解決されていなかったり、別の新しい問題が生まれてしまい結局恩恵が感じられない、といった状況は避ける必要があります。 そのためには、システム的な観点だけでなく、運用的な観点でも設計を行ったり、運用ルールを定め、それを守り続ける文化の醸成まで必要なことは多岐に渡ります。
具体例を出すと、

といったものがありますが、これはほんの一例にすぎません。ただインフラをコード化するだけでは全くもって不十分なのです。 IaCを導入することにした目的を常に忘れず、新たな問題が出ていないかを確認することが重要です。

移行によってもたさられたもの

1. コンテナ化による利点

コンテナ化する利点は一般的にも語り尽くされているとは思いますが、当事者として感じた大きな利点をご紹介いたします。

VM上でホスティングしている時は、メインのアプリケーションプロセスだけでなく、様々なプロセスが稼働しています。どの変更がメインのアプリケーションプロセスにどのような影響を及ぼすのかの入念な確認が必要になってきます。結果的に、変更したくないという思いが高まり改善活動に対して腰が重くなっていました。本番環境へのリリースだけでなく、開発環境においても、復旧に時間のかかるような設定変更をしてしまわないようにといった思いを抱えながら開発業務を行っておりました。
一方コンテナは、どんなに変更をしても影響範囲はそのコンテナに留まるので、変更作業や検証に対する心理的なハードルが大幅に下がります。例えミスを犯してしまっても、コンテナの設定はコードで定義しているので、簡単に元の状態に戻すことができます。一つ一つのコンテナという意味でも、Kubernetesクラスター全体という意味でもコードによって定義を行うので、環境全体の把握や実機との差異も捉えやすくなります。

2.あらゆるものが可視化されるようになった

AWSに移行したことにより、

といった改善が見られました。
これによりエンジニアは自分たちのシステムを深く理解できるようになり、安心して運用を行えるようになりました。それに伴って、サービスの機能追加なども積極的に行えるようになるというビジネス的な利点も獲得することができました。

3.外部サービスやネットワークとの連携のしやすさが大幅に向上した

例えばシステムの監視はAWSの中だけでも完結して実施することができますが、私たちは別の専用ソリューションを用いておりました。AWSで提供されるメトリクスをそのまま外部ソリューションに連携できたり、ログを連携する仕組みなども標準化されています。またネットワークの観点においても、Transit GatewayやDirect Connect、Site to Site VPNなど多くのサービスが存在し、状況に合わせて利用できるだけでなく、手軽に利用開始ができます。こういった外部のサービスやネットワークとの連携のしやすさが大幅に向上したのも、移行して得られた恩恵です。

4.カスタマーサポートの圧倒的な質の高さ

カスタマーサポートというのは、思っているよりも非常に重要です。障害原因の切り分けや復旧のサポート、開発業務時の困りごとまでその用途は多岐に渡ります。 AWSを利用して強く感じるのは、サポートの圧倒的な質の高さです。プライベートクラウドを提供していたサービスでは、英語での問い合わせが必須であったり、回答までの速度がまちまちであったりといった問題がありました。一方AWSでは、日本語でのサポートはもちろん、回答までのスピードもほぼ一定であり、こちらが質問している以上の内容を推測して回答していただいておりました。回答の質の水準も高く、どの方も真摯に向き合っていただける印象でした。
サポートの質向上が移行における第一の目的として語られることはほとんどないと思いますが、非常に重要であり、それだけでも移行する価値があると感じました。
GatewayやDirect Connect、Site to Site VPNなど多くのサービスが存在し、状況に合わせて利用できるだけでなく、手軽に利用開始ができます。こういった外部のサービスやネットワークとの連携のしやすさが大幅に向上したのも、移行して得られた恩恵です。

評価

移行前に存在していた問題が移行後に解消されたのかを改めて振り返ってみます。