Blog
サーバーレスコンピューティング：BSSデータ移行における運用の複雑さを軽減し、高速化とコスト削減を実現
サーバーレスコンピューティングは、現在パブリッククラウド環境で大きな注目を集めている最新技術です。その盛り上がりから、ソフトウェアエンジニアリングに変革をもたらし、運用の複雑さを解消して、開発者が機能性とユーザー体験に完全に集中できるようになると期待されています。ワークロードの変化に応じてインフラをプロビジョニングする必要がなく、アイドル時間に対して料金を支払う必要もない点は確かに魅力的です。しかし、輝くものすべてが金ではないように、すべてを鵜呑みにせず、ある程度の慎重な見方を保つことが賢明でしょう。
Beyond Nowでは、AWSのサーバーレステクノロジーをかなり以前から活用しており、それによってお客様に多くのメリットをもたらしてきました。私は、レガシーシステムから新しいIT環境へのデータ移行におけるサーバーレステクノロジーの活用を検討してきました。これは、IT変革プロジェクトを進める際に一般的に悪名高い課題です。データは旧環境から扱いにくいインターフェースを通じて抽出され、その後クレンジング、変換が行われ、お客様やバックオフィス担当者の停止時間を最小限に抑えながら、新しい環境へシームレスにロードされる必要があります。
おそらく、移行先のシステムはすでにクラウドネイティブであり、弾力性、スケーラビリティ、堅牢性といった大きな利点をすべて備えています。SaaSソリューションへの移行である可能性もあり、その場合、スケーラビリティや容量管理、パフォーマンスチューニング、インフラ保護、モニタリングなどを含むインフラ全体はもはや懸念事項ではなく、SaaSソリューションプロバイダーが対応します。したがって、データクレンジングに加えて、移行スクリプトのコードが正しく動作し、プロセス全体のパフォーマンスボトルネックにならないことを確認するだけで済みます。
多くの点で、ほとんどのデータ移行プロジェクトの作業の大半は従来のシステム統合タスクと比較的似ているため、必ずしも新しいソフトウェアを購入する必要はありません。重要なのは、データを正しく自動変換し、新しいシステムの適切なAPIを呼び出してデータをロードすることです。ただし、システム統合と比べて移行プロジェクトを実装する際には、いくつかの違いがあります。
サーバーレステクノロジーは、移行プロセスでデータの変換とロードに必要な機能を実装するための理想的な候補です。AWS Lambda のようなサーバーレスコンピューティングプラットフォームを使用して、任意のプログラミング言語で変換ロジックのマイクロサービスを実装できます。さらに、AWS Step Functions のようなサーバーレス関数オーケストレーターを使用して、データの抽出・変換・ロードのプロセスにおける変換ステップやAPI呼び出しをオーケストレーションできます。インフラは透過的にスケールするため、新しいテスト環境を短時間で立ち上げることができ、少量のデータをシームレスに処理するだけでなく、新しい環境のプロビジョニングを心配することなく、フルデータセットでのテストも可能です。料金が発生するのは、データが実際に処理されているときのインフラ利用分のみであり、コードがアイドル状態で移行テストを実施していない間はコストは発生しません。
直近のBSS変革プロジェクトでは、AWSのサーバーレステクノロジーを用いてデータ移行プロセスを実装しました。データを変換し、APIを通じてターゲットシステムへロードする一連のプロセス全体は、AWS Step Functions によってオーケストレーションされた AWS Lambda を使用して実装されました。移行プロセスのソースデータは S3 バケットに保存され、フローのステータス管理には AWS DynamoDB が使用されました。移行プロセスは、使いやすくテストしやすいように、Amazon API Gateway を介したREST APIとして公開されました。
このアーキテクチャにより、開発開始からわずか2週間後には実データを用いた最初の移行テスト実行を行うことができました。そこから、すべてのデータ品質上の問題が解決されるまで、変換関数を反復的に改善し、移行のテストを実施しました。サーバーレスアーキテクチャのおかげで、テスト環境の起動や停止のためにインフラをプロビジョニングする必要がなく、いつでもテスト実行を行えたため、データクレンジングのプロセスを大幅に加速できました。
大規模なデータセットも、重いテストインフラのコストや、いくつの環境を確保できるかという終わりのない議論を心配することなく、いつでも処理できました。データ移行の開発およびテストの全期間を通じて、月間インフラコストは10米ドル未満に抑えられました。1回のテスト実行にかかった費用も、わずか数セントを超えることはありませんでした。これは、同規模のプロジェクトでパブリッククラウド上に従来型の開発・テストインフラを構築した場合に発生していたであろうインフラコストの、おそらく10%未満でした。
もちろん、このシナリオで移行するデータ量は膨大ではなく、加入者数は20万件をわずかに超える程度でした。しかし、数百万件の顧客レコードを移行する場合であっても、実質的に無制限で非常に高性能なテスト環境を利用しても、月額コストは数百米ドル程度を超えないと考えています。そして何より、より多くの顧客数に対応するためにソリューションをスケールさせる際にも、インフラをプロビジョニングする必要はありません。
サーバーレスコンピューティングは依然として比較的新しい概念であるため、その具体的な利点については曖昧さが残っており、今後に向けて対処すべき課題があることは明らかです。サーバーレスプログラミングに関するスキルギャップは予想されることですが、私の意見では、最大の課題は依然としてサーバーレステクノロジーの利用におけるコスト見積もりです。
単一のLambda関数について、リクエスト数、処理時間、GB秒単位のメモリ割り当てといった指標を把握したり、DynamoDBのようなサーバーレスデータベースにおける読み取りおよび書き込みリクエスト数を予測したりすることは不可能です。実際には、ワークロードが常時稼働ではなくピーク時にスケールアップする必要がある場合、サーバーレステクノロジーはプロビジョニングされたインフラよりも安価になるという知見に頼る可能性が高いでしょう。コストを最適化するためには、ソフトウェアアーキテクトは設計において基盤サービスの課金指標も考慮する必要があります。
