新しいツールを開発しながらクラウドを導入し、パワーアップした HSBC
Google Cloud Japan Team
※この投稿は米国時間 2019 年 9 月 26 日に Cloud Blog に 投稿されたものの抄訳です。
編集部注: 今回は、世界有数の国際的な金融機関である HSBC の事例をご紹介します。HSBC では Google Cloud エンジニアと緊密に連携し、カスタムビルドのツールと自動化最優先のアプローチを用いて、従来のデータ ウェアハウスを BigQuery に移行しました。これにより、データ分析機能が飛躍的に向上し、忠実度の高いデータを取得できるようになりました。
HSBC では 66 か国にわたって、消費者から企業まで 3,900 万以上のお客様に対面およびオンラインでサービスを提供しています。データセンターを 21 か国に構え、サーバー数は 94,000 台を超えます。オンプレミスのインフラストラクチャを使用したビジネスの運用では、容量の問題が常につきまとい、これがイノベーションの阻害要因、ひいてはビジネス上の制約になっていました。社内のチームは、より良い商品やサービスを生み出すためにデータを最大限に活用することを望んでいましたが、所有していたテクノロジー ツールでは実現できていませんでした。このような状況の中、データは増え続けており、あるデータ ウェアハウスでは 2014 年から 2018 年までの間にデータ量は 300% も増加しました。
膨大な量のデータがあっても、そこから分析情報やビジネス価値を得ることができなければ何の意味もありません。お客様に最適な方法で、柔軟にサービスを提供したいと考えていました。
クラウドに移行すれば、保存して処理できるデータ量が増えることはわかっていましたが、国際的な銀行である当社のシステムは複雑で、安全性も重要でした。Google と協力してプロジェクトの範囲と戦略を前もって策定することで、移行を成功させることができました。クラウドに移行したことで、アジャイルな DevOps のマインドセットを使用できるようになり、途中で自動化を組み込みながら、早い段階で失敗を重ねて、より小さなワークロードを提供できるようになりました。また、移行によって技術的負債がなくなり、インフラストラクチャの管理よりもイノベーションに集中できるデータ プラットフォームを構築できました。こうして移行を継続しながら、新しいテクノロジーを考案し、それを使用できるプロセスを構築していきました。
クラウドへの移行の計画
クラウドに移行することを決めたのは、当社のビジネスにおけるデジタルの可能性を最大限に引き出すにはクラウド機能が必要だとわかっていたからです。Google Cloud、特に BigQuery を採用した理由は、データセットの規模にかかわらず極めて高速に処理できるうえに、SQL インターフェースと接続シートの両方を使用して対話できるためです。データとそのスキーマをクラウドに移行する必要がありましたが、細部を手動で管理する必要はなく、設定したスケジュールに支障をきたすこともありませんでした。当社のデータ ウェアハウスは巨大で、複雑かつミッションクリティカルであり、既存のリファレンス アーキテクチャに簡単に適合させることはできませんでした。効率的に移行できるように事前に計画を立てて自動化し、途中でデータやプロセスを簡略化できるようにする必要がありました。
最初に移行したレガシーなデータ ウェアハウスは 15 年間かけて構築されたもので、数百万件のトランザクションと 180 TB のデータを含み、30 年分のデータ価値がありました。6,500 件の抽出、変換、読み込み（ETL）ジョブと 2,500 を超えるレポートを実行し、約 100 個のソースからデータを取得していました。クラウド移行では通常、リエンジニアリングかリフト＆シフトのどちらかの方式が選択されますが、当社では「移動と改善」という別の戦略を採用しました。これにより、容量や柔軟性といった BigQuery の機能を最大限に活用でき、容量の制約という重要な問題を解決できました。
クラウドへの第一歩
まず行ったのは、マッピングを通じたクラウド戦略の構築です。これにより、社内チーム間でチェンジ マネジメント プロセスを開始することもできました。移行アプローチとして、Architecture Decision Records（ADR: アーキテクチャ意思決定の記録）を採用しました。これにはアジャイル ボードを使用して作成した技術的ユーザー ジャーニー マップがベースとして使用されました。ユーザー ジャーニーには、「変更データのキャプチャ」「製品イベント処理」「緩やかに変化するディメンション」などが含まれます。
これらは移行にあたって取り組まなければならないデータ ウェアハウスの一般的なテーマであり、この他に金融サービス業界固有のテーマもありました。たとえば、データ ウェアハウスに特定の時点での整合性のあるゴールデン データソースがあることを確認する必要がありました。ビジネスへの影響も考慮して、最初にアーカイブと履歴データを優先的に移行し、古いシステムの負荷を即座に取り除きました。また、データ ウェアハウスのユーザーがクラウドへの移行に備えられるように、ハードウェアの管理ではなくクエリや割り当ての管理を行うなど、早い段階で指標を確立して新しい概念を導入していきました。
移行量を減らすために、データ ウェアハウスに現在保存されているデータを調べて、それらが使用されているかどうかも確認しました。関係者と協力してレポートを評価したところ、使用されておらず、廃止しても差し支えないレポートが 600 以上見つかりました。また、運用サポートチームの夜間の作業量を減らせるように、ETL ジョブを簡略化して以前の移行で増加した技術的負債を取り除く方法も検討しました。
データの移行は 3 段階に分けて行いました。最初にスキーマを BigQuery に移行しました。次にレポートの負荷を BigQuery に移行し、メタデータのタグ付けを追加して調整プロセスを行いました。最後に、履歴データのすべての SQL スクリプトを BigQuery に対応したスクリプト データに変換して移行しました。
移行を自動化する新しいツールの作成
当社の自動化方針に沿って、移行を高速化するアクセラレータをいくつか開発しました。これらは、設定したスケジュールに間に合わせ、人為的ミスを排除するために開発したものです。
スキーマ パーサーとデータ調整ツールを利用することで、データレイヤを BigQuery に移行することができました。SQL パーサーでは、データアクセス レイヤを Google Cloud Platform（GCP）に移行できました。これにより、データ系統やドキュメントのない 3,500 個の SQL インスタンスを個別に移行する必要がなくなり、ワークロードの優先順位付けに役立ちました。また、データ系統ツールにより、レイヤ全体からコンポーネントを特定して依存関係を見つけました。これは、計画段階で統合の問題を見つけて解消したり、移行中にアプリケーションの所有者を特定したりするのに不可欠なツールとなりました。最後に、データ調整ツールでデータソースとクラウドのデータ ターゲット間の不一致を調整します。
クラウドの未来を構築
英国のデータセンターで行った、この最初の移行をテンプレートとして使用することで、今後は自信を持ってカスタマイズしたプロセスやカスタムツールを使用できます。当社の慎重なアプローチは、チームやお客様にも良い結果をもたらしています。そしてより良い開発を行えるようになり、テスト手順も改善されました。アプリケーションのオンボーディング パスを作成して、単一の情報源としてデータ ウェアハウスを使用し、承認済みビューを使用して安全なデータアクセスを実現しています。BigQuery の柔軟性とスケーラブルな容量により、ユーザーは制約なしにデータを探索でき、お客様は必要な情報をよりすばやく取得できるようになりました。
- By Srinivas Vaddadi, Delivery Head, Data Services Engineering, HSBC
