【ITニュース解説】The AWS Service We Regret Using — And How We Migrated Off It

システムを開発する際、どの技術を使うか、どのクラウドサービスを選ぶかは非常に重要な決断となる。特にクラウドサービスは、一度導入すると後から変更するのが難しい場合も多く、初期の選択が数年間にわたって影響を与えることがある。この記事では、ある企業がAWS (Amazon Web Services) の特定のサービスを選定したことを後悔し、最終的に別のサービスへ移行するまでの経緯と、そこから得られた教訓について解説する。

この企業が最初に選んだサービスは、Amazon Managed Blockchain (AMB) だった。AMBは、複数の企業や組織が共通の情報を共有し、その変更履歴を誰にも改ざんできない形で記録・検証できる「ブロックチェーン」という技術をクラウド上で簡単に利用できるようにするサービスだ。特に、参加者が限定される「許可型ブロックチェーン」の一種であるHyperledger Fabricという技術を基盤としており、参加者の身元を明確にし、取引のプライバシーを確保したい場合に適していると考えられた。企業は、自分たちも複数のパートナー企業とデータを安全に共有し、変更履歴を確実に管理したいというニーズがあったため、このAMBが最適な選択肢だと判断した。また、AWSが提供する「フルマネージドサービス」である点も魅力的だった。フルマネージドサービスとは、サーバーの管理やソフトウェアの更新といった面倒な運用作業をAWSが全て代行してくれるため、開発者はアプリケーション開発に集中できるというメリットがある。この企業も、運用負荷を減らし、開発を効率的に進めたいという期待を抱いていた。

しかし、実際にAMBを使ってみると、いくつかの深刻な問題に直面することになる。最も大きな問題の一つが、予想をはるかに超える「コスト」だった。AMBは、ネットワークを構成する各要素（メンバーシップ、ノードなど）に対して料金が発生し、開発環境であっても本番環境とほぼ同等の費用がかかってしまった。これにより、開発やテストを繰り返すたびに高額な費用が発生し、プロジェクト全体の予算を圧迫する結果となった。また、「運用上の複雑さ」も課題だった。フルマネージドサービスのはずが、実際にはブロックチェーンネットワークの構築や設定が非常に複雑で、リージョンの選択やメンバーシップの追加、ノードのプロビジョニングといった多くの手動作業が必要だった。さらに、AMBの基盤であるHyperledger Fabricのアップグレードは自動で行われず、手動での実施が必要であり、その際にはサービスの停止（ダウンタイム）が発生するリスクもあった。複数のノードから出力されるログの管理も容易ではなく、分散された情報を集約・分析するための工夫が求められた。

さらに、「パフォーマンスの課題」も顕著だった。新しいブロックチェーンノードをネットワークに追加する際、既存のすべての取引履歴を同期するのに非常に長い時間がかかり、実用的な速度ではなかった。データの読み込み（クエリ）にも時間がかかり、リアルタイムでのデータ参照が求められるアプリケーションでは使い物にならない場面もあった。このような課題は、単に技術的な問題に留まらず、プロジェクトの進行を遅らせ、ビジネスの機会損失にも繋がりかねない状況だった。加えて、AMBはAWS独自のブロックチェーンサービスであるため、将来的に他のクラウドプロバイダーへ移行しようとした際に、技術的な互換性が低く、移行が非常に困難になる「ベンダーロックイン」のリスクも懸念された。AMB特有の知識が必要となるため、開発チームが習得するまでの学習コストも高く、期待していた効率性とはかけ離れた状況だった。

これらの問題を総合的に判断した結果、企業はAMBの利用を継続することは困難であり、よりコスト効率が良く、運用がシンプルで、高性能な代替サービスへ移行することを決断した。特に、ブロックチェーンの主要な目的であった「データの改ざん防止」と「履歴の検証可能性」という要件を満たしつつ、他の課題を解決できるサービスを模索した。

そこで見つけ出したのが、同じくAWSが提供する「Amazon QLDB (Quantum Ledger Database)」だった。QLDBは、一般的なデータベースとは異なり、追加されたデータを決して変更したり削除したりできない「台帳データベース」という特性を持っている。これにより、ブロックチェーンと同じように、記録された情報の改ざんを防止し、すべての変更履歴を確実に検証できる。この特性は、企業がAMBに求めていた中核的な要件を完全に満たしていた。QLDBの最大の魅力は、AMBと比較して「圧倒的に安価」であることだった。QLDBはデータの書き込み量や読み込み量に応じた従量課金制であり、開発環境でのコストを大幅に抑えることができた。また、「運用上のシンプルさ」も特筆すべき点だった。QLDBは完全にフルマネージドサービスであり、ノード管理やバージョンアップ、スケーリングといった煩雑な作業はAWSが全て自動で行ってくれるため、開発者はデータベースの運用について心配する必要がほとんどない。

さらに、QLDBは「高いパフォーマンス」も提供した。高速なトランザクション処理とクエリ応答速度を実現し、リアルタイム性が求められるアプリケーションにも十分対応できる性能を持っていた。データの読み書きにはSQLライクなクエリ言語を使用できるため、多くのシステムエンジニアにとって馴染み深く、「学習コスト」もAMBに比べて格段に低かった。これらの利点から、QLDBがAMBの代替として最適であると判断された。

移行プロセスは慎重に進められた。まず、新しいシステム（QLDB）と既存のシステム（AMB）の両方にデータを書き込む「デュアルライト」という方法を導入した。これにより、既存システムに影響を与えることなく、新しいシステムへのデータ書き込みが正しく行われているかを確認できた。次に、AMBに蓄積されていた過去のデータをQLDBへ移行する作業を行った。これは、特別なスクリプトを開発し、データを効率的に移し替えることで実現された。その後、アプリケーションのコードを、AMBを利用する部分からQLDBを利用するように書き換え、すべての機能が正しく動作するかを徹底的にテストした。最終的に、全ての準備が整った段階でAMBへの書き込みを停止し、QLDBを本番環境として稼働させることで移行が完了した。

この一連の経験から得られた教訓は非常に大きい。まず、新しい技術やサービスを導入する際は、その見た目の利点だけでなく、「長期的なコスト」「運用上の手間」「将来的な拡張性（スケーラビリティ）」を初期段階で徹底的に評価することの重要性だ。また、いくら「フルマネージドサービス」と謳われていても、その内部でどのような仕組みが動いており、どのような制約があるのかを深く理解しておく必要がある。特定のユースケースに特化したニッチなサービス（今回のAMBのようにブロックチェーン特化型）を選ぶ前に、より汎用的なサービス（QLDBのように汎用的な台帳機能を持つもの）で要件を満たせないか検討することも賢明な判断だ。そして、特定のクラウドプロバイダーに過度に依存しすぎないよう、「ベンダーロックイン」のリスクを常に意識しておくべきだろう。システムの基盤となるサービス選定は、プロジェクトの成功を左右する重要な要素であり、将来を見据えた慎重な検討が不可欠である。