re:Invent 2024: GE VernovaのCassandraからAmazon Keyspacesへの600TB移行
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Powering the grid: GE’s 600 TB migration to Amazon Keyspaces (DAT318)
この動画では、GE Vernovaが600テラバイトのデータをApache CassandraからAmazon Keyspacesに移行した事例が紹介されています。Amazon KeyspacesはCassandraと互換性のあるサーバーレスデータベースで、運用の簡素化とスケーラビリティを実現します。GE Vernovaのチームは、300のエンタープライズ顧客のデータを6ヶ月以内に移行するという課題に直面し、AWS GlueやLambdaを活用した大規模な並列処理を実装しました。移行中もシステムを停止することなく、Point-in-Time Recoveryやテナンシーモデルの改善など、多くのメリットを獲得。AWS ProServとの密接な協力関係や、日次での進捗管理、早期の検証開始の重要性など、大規模データ移行における具体的な学びが共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Keyspacesへの大規模データベース移行：イントロダクション
おお、まだ学び続けているんですね。本当に素晴らしいことです。最後まで粘り強く参加されている皆さんこそが本当のスーパースターですので、ぜひ自分自身に拍手を送ってください。週末近くのこの時間帯にお越しいただき、ありがとうございます。この1週間、皆さんは様々な新しいテクノロジーについて学び、それをどのように活用できるか考え、そして持ち帰ることに胸を躍らせていることと思います。ただ、アイデアを実際のプロダクションに移すのは、そう簡単ではありませんよね。今日のトークでは、Amazon Keyspacesへの大規模なデータベース移行についてお話しします。
本日は、GE Digitalのヨギーニ・パルキさんをお迎えして、彼女のチームがどのようにワークロードをAmazon Keyspacesに移行したのか、その道のりについてお話しいただきます。このトークはデータベース移行に関するものですが、アプリケーションのモダナイゼーションを行う際のベストプラクティスについても触れていきます。これらのヒントやコツに耳を傾けていただければ、データベース以外の分野でも必ずお役に立つはずです。
Apache CassandraとAmazon Keyspacesの概要
アジェンダの最初は、Apache Cassandraのためのサーバーレスデータベースであり、CQL互換のAmazon Keyspacesについてです。まず、Apache Cassandraとその仕組みについて、特に運用担当者や管理者が気にかける点に焦点を当てて説明します。会場の中でCassandraをお使いの方はいらっしゃいますか？実際にプロダクションで使用している方は？少し手が挙がりましたね。今日は皆さん、Cassandraについてたくさん学んでいただけると思います。Cassandraの内部の仕組みや、モデリングの方法、その用途について深く掘り下げることはしませんが、歴史と、管理者や開発者として知っておくべき主要なコンポーネントについてお話しします。
その後、Amazon Keyspacesについて説明し、サーバーレスとは何を意味するのか、そして運用面でどのように作業を簡素化し、皆さんがCassandraという素晴らしいテクノロジーに集中できるようにしているかをお話しします。そして、GEでの移行についてヨギーニさんにバトンタッチします。 さて、Cassandraですが、これはオープンソースのNoSQLワイドカラムデータベースです。2008年にFacebookによってApacheに寄贈されました。2008年当時、水平方向にスケーラブルなデータベースは市場にほとんどありませんでした。そこで彼らは、高可用性があり、分散型で、一般的なハードウェアで動作し、単一障害点のない独自のデータベースを開発しました。つまり、問題が大きくなるにつれてハードウェアを追加していけば、それに応じて適切にスケールするということです。
Cassandraをサービスとして説明する最も良い方法は、可能な限り最もシンプルなCassandraインスタンスの構成図を描くことです。Cassandraは本質的にモノリスで、実行されるバイナリは1つだけです。後ほどCassandraホストのリングやクラスターがどのように連携して動作するかについてお話ししますが、まずは単一のホストの視点から、運用担当者として気にすべきポイントについて説明します。コンピュートリソースが必要な場合、何らかの環境で実行する必要があります - ここではEC2インスタンスを例として挙げていますが、これは任意です。ラップトップでも、無理すればRaspberry Piでも動作するかもしれません。aptやYum、Snapなどを通じてバイナリをダウンロードして展開すれば、実行可能なバイナリが手に入ります。
デフォルトでは、ディスク上にこれら4つのディレクトリが作成されます。これらは変更可能で、チューニングに関する多くの設定がありますが、今回は詳しく説明しません。実は、Cassandraの管理が難しい理由の1つは、調整が必要なパラメータが多すぎることなんです。管理者として、これら4つのディレクトリはスケーリングを考える上で最も重要なポイントの1つです。最初のデータディレクトリは、実際のデータが保存される場所です。データベースに保存されたものはすべてディスクにフラッシュされ、そこに保管されます。Commit logについては、Cassandraはwrite-ahead logと呼ばれる技術を使用しています。これはログファイルに追記を行い、その追記が成功すると、基本的に書き込みが成功したとみなされる仕組みです。
クラスター内に他のCassandraインスタンスがあり、レプリケーションを設定していて、「保存が必要なデータがありますよ」と他のホストに通知しようとした時に、そのホストが何らかの理由でダウンしている場合、そのホストが復帰するまでメッセージはhinted handoffフォルダに保存されます。 最後に、他のサービスと同様にlogフォルダがあり、クライアントは直接そのホストに接続します。クライアントは通常、デフォルトでそのホスト上にあり、cqlshとCQL（Cassandra Query Language）が提供されます。CassandraがSQL風の構文やテーブルなどの馴染みのある概念を持っているため、従来のRDBMS開発者にとって非常に取り組みやすいというのが、人気の理由の1つです。ただし、リレーションはありません。
これらのコンポーネントはすべてデータを消費して容量を使用するため、管理者による監視が必要です。
Cassandraの内部動作と管理上の課題
ここで、Cassandraに書き込みリクエストが来た時に何が起こるのか、そしてディスク上のファイルをどのように使用して書き込みの成功を通知するのかについて説明しましょう。最初に行われるのは、write ahead log（つまりcommit log）への追記で、 受け取ったメッセージをインメモリのデータ構造に保存します。これにより、運用時のスケーリングを考える上でもう1つの要素が加わります。というのも、memtableと呼ばれるこのインメモリデータ構造は、サイズを設定できますがRAMを使用するため、その点に注意を払う必要があるからです。
これら2つのステップが完了すると、クライアントに「200、書き込みを受け付けました」と返信します。異なる ノードにデータをレプリケートする必要がある場合は、それらのノードに直接呼び出しを行い、最初の2つのステップ（追記とmemtableへの保存）を同様に実行します。このプロセスは、設定されたクォーラム（全ノードの承認が必要か、一定数のノードの承認で良いか）に従います。ノードが利用できない場合、データはhinted handoffフォルダに保存されます。memtable が一杯になると（これは設定可能な値です）、対処が必要になります。memtableには最近追加されたデータが含まれており、Cassandraではこれをメモリ内に保持します。ディスク上のデータファイルを見る前に、まずmemtableをチェックしますが、これはインメモリデータベースではないため、単なる最適化としての制限があります。
ある一定のポイントに達すると、それをディスクにフラッシュし、データディレクトリをSSTables（Sorted String Tables）の形式で格納します。ここからは、SSTables（ソート済み文字列テーブル）とは何か、管理者として必要な操作、その仕組み、そして最も重要なDBA操作であるCompactionについて詳しく説明していきます。
Cassandraでは、Column FamiliesとTablesという用語は互換的に使用されています。テーブルにはColumnがあり、歴史的にはColumn Familiesと呼ばれていましたが、最近ではその用語は使わなくなり、単にTableと呼んでいます。テーブルは複数のSSTablesで構成されており、それぞれが個別のファイルになっています。ディスク上でlsコマンドを実行すると、多くのSSTablesが表示されます。各SSTableは1つの実際のテーブルに関連していますが、そのテーブルは多くのSSTablesを持つことができます。例えば、ファイル1と2はテーブルAの一部で、ファイル3と4はテーブルBの一部というような具合です。
これらのファイルの内容を見ると、1行目にはただのデータがあります。2行目には期限切れのデータがあり、これはTTL（Time To Live）の概念に関連しています。書き込みの際に、そのレコードのTTLを指定することができます。読み取り時には、そのデータは技術的にはまだテーブルに存在し、スキップされますが、スペースは消費されたままです。もう1つの概念はTombstoneです。Cassandraで何かを削除する場合、データを即座に削除するのではなく、Tombstoneマーカーを付けます。4行目にはデータがあり、6行目には将来のTTLがあります。これは将来的に期限切れになりますが、まだその時期には達していないということです。
このプロセスはMemtableがフラッシュされるたびに発生し、担当するテーブルに基づいて新しいSSTablesを作成します。そして、Compactionのプロセスが必要になります。Compactionは、これらのSSTablesを処理し、テーブルごとのSSTableの数をできるだけ少なくすることを目的としています。TTLで期限切れになった行やTombstoneを削除することでガベージを除去し、保持すべきものを残します。左側では、将来のTTLを保持し、Tombstoneレコードを削除しています。この短い期間、データは重複して存在することになります。保存・維持しようとしているものすべてが、この時点で2つのファイルに存在しているのです。
データスペースが限られている場合、実際には2倍のスペースを消費していることになります。Compactionプロセスが完了し、その完了を確認できたら、Cassandraはそれらを削除します。これは1つのノードでの話でしたが、これは全く同じ方法ですべてのノードで発生します。Cassandraのノードには特別な性質はなく、すべてのノードが実質的に同等です。
Amazon Keyspacesのアーキテクチャと利点
必要な数のノードを追加してToken ringを作成することができます。これはCassandraでの専門用語です。Token ringは基本的に、Cassandraノード全体に均等に分散されたハッシュ値の範囲です。ここでは説明しやすいように4つのノードを任意に選んでいます。ハイライトしているハッシュ範囲は128ビットのキーです。入力される各Partition keyはハッシュ化され、そのハッシュ値によってデータの所有者が決定され、各ノードがその範囲の4分の1を担当することになります。
これを3つの異なるPartition keyを含むテーブルで視覚的に示します。それぞれのキーはハッシュ関数を通して処理され、そのデータを主に担当するノードが決定されます。これらのノードはクラスターとして動作し、先ほど説明したように、ハッシュToken ringの分散方式に従って相互に通信を行います。各ノードは自身が担当するToken rangeについて情報を共有し、協力して動作します。あるノードがダウンした場合も、その情報を互いに共有します。
複数のノードについて説明したところで、Replication factorについてお話ししましょう。一般的なReplication factorは3です。Quorumベースのシステムでは、奇数が必要で、Quorumは全ノード数を2で割って切り上げた数となります。通常、3つのコピーを確保するためにReplication factor 3を使用し、2つの値が一致した場合、それが正しい値であると確信できます。書き込みリクエストが任意のノードに到達した際、そのノードが特定のPartition keyを担当していない場合でも、Coordinatorという特別な役割を担うことができます。Coordinatorはハッシュ関数を使用して、プライマリToken rangeの担当を決定し、そこに最初に書き込みを行い、その後バックアップとしてToken rangeを共有する他のノードにも書き込みを行います。設定された読み取り要件（全数またはQuorumなど）が満たされると、すぐにクライアントに200ステータスを返します。
Cassandraに関する多くの専門用語について説明してきました。これらは管理者が考慮すべき事項です。主に、適切なクラスターとノードを確保することが重要です。私たちは6,000ノードまでのデプロイメントを見てきました。単一ノードの問題が6,000倍や10,000倍になると、非常に困難な状況になります。そのため、監視とアラートシステムの導入、バックアップとリストア機能の実装、災害復旧対策が必要になります。より良い分散を実現するためにPartition keyをよりスパースにするなど、システムを調整する様々な方法があります。
次に、Amazon Keyspacesについて、そしてこれらの管理作業をいかにシンプルに、あるいは不要にして、アプリケーションに集中できるようにするかについてお話ししたいと思います。まず、KeyspacesはCQLと互換性があります。つまり、オープンソースのアプリケーションコードやドライバーを変更することなく使用できるようにシステムを設計しました。エンドポイントをKeyspacesに変更するだけで動作します。これは、AWS SDKを使用する他の多くのサービスとは異なります。また、Serverlessであるため、OSのパッチ適用やアプリケーションのパッチ適用、Compactionの処理など、そういった作業を行う必要がありません。
ディスク容量のオーバーヘッドについて心配する必要はありません。必要のない追加のフリートのプロビジョニングは、すべて自動的に処理されます。また、どのようなデータ規模でもシングルディジットミリ秒のパフォーマンスを提供しており、その仕組みと、Cassandraとの根本的な違いについてすぐにご説明します。これまで共有していなかった秘密のベールを少し取り除いてお見せしましょう。そこまでドラマチックな内容ではありませんが、私たちがCassandraとは異なるアーキテクチャを採用した方法について、新しい情報をご紹介します。
マルチリージョンレプリケーションとデータの保存時の暗号化により、99.999%の可用性で高可用性とセキュリティを実現しています。また、PITRと呼ばれる機能も提供しています。これはPoint-in-Time Recoveryの略で、ミリ秒または秒単位でシステムの状態を捉えたスナップショットを取得します。そのため、DRイベントが発生した場合や、意図しない操作を行ってしまった場合でも、APIコールを使用して特定の時点まで巻き戻して再生することができます。
それでは、アーキテクチャについて少し詳しく見ていきましょう。長くはかかりません、あと数分程度です。Cassandraとの違いと、私たちがどのように異なるスケーリングを実現しているかについてハイライトしていきます。先ほど申し上げたように、Cassandraクライアントは直接Cassandraホストに接続していましたが、Amazon Keyspacesでは、同じクライアントが私たちのエンドポイントの1つに接続します。そのエンドポイントはNetwork Load Balancerに転送されますが、これはCassandraでは実現できない機能です。Cassandraではトークンリングでロードバランシングを行いますが、私たちはNetwork Load Balancerを導入することで、ワークロードに合わせて多数の接続を柔軟に調整できるようにしました。また、クエリとリクエストの処理をデータストレージから分離しました。
Cassandraではこれらが1つのモノリスになっていますが、この分離により、異なる速度でスケールすることが可能になります。NLBはクエリリクエストハンドラーに転送し、クエリを解析して、どのストレージノードが担当するかを決定し、そのデータを3つの別々のAvailability Zoneに書き込みます。1つのコピーだけを書き込むことは危険なので許可していません。また、同じラックや同じAvailability Zoneに配置されないようにしています。これらはすべてデフォルトで行われます。そして、ここが秘密の部分ですが：これはDynamoDBで使用されているのと全く同じストレージテクノロジーなのです。DynamoDBには上層に多くのルーティングやリクエスト層がありますが、私たちは長年にわたってシステムの基盤として、非常に耐久性が高く回復力のあるストレージネットワークを構築してきました。
Amazon Keyspacesのストレージ層にこれを使用することにしました。そのため、DynamoDBと同じようなパフォーマンスと耐久性の保証が得られます。もう1つの違いは、Cassandraではパーティションキーが1つのホストに解決されるということです。仮想ノードや仮想トークンのような対策を取らない限り、そのホストに対してアクセスし続けることになります。しかし、Amazon Keyspacesでは、特定のキーに対するトラフィック量を監視し、多すぎる場合はホットキーとみなして分割します。つまり、ある時点でそのストレージノードに格納したい最大データ量に達したと判断すると、分割を行います。この処理は無限に続けることができます。そのため、どれだけのデータを投入しても、これらのノードを分割し続けることができ、それによってどのようなスケールでも同じパフォーマンスを保証することができるのです。
GE VernovaのAmazon Keyspaces移行プロジェクト：背景と課題
同様に、クエリとリクエストの処理についても同じことができます。つまり、もしワークロードがIoTやテレメトリーのような、小さなデータで多くの接続を持つものであれば、クエリリクエストの処理をスケールさせる方が理にかなっています。大量のデータを扱う場合や、過去に遡る大量のレガシーデータがある場合は、ストレージを異なるレートでスケールできます。重要なポイントは、私たちがServerlessであるということです。つまり、管理作業を行う必要がありません。ストレージとルーティングの懸念事項を分離し、Apache CassandraのCQL言語と互換性があり、何より使用した分だけ支払えばいいのです。これは、特に大規模なCassandraのインストールで私が目にした最大の課題の一つでした。バーストやCompactionなどを予測できないため、多くの場合、過剰にスケールされていたのです。
以上で私のパートは終わりです。ここでマイクをYoginiに渡して、GEでの取り組みについて話してもらいます。ありがとう、Steve。この拍手はSteveへのものですね。私はYoginiです。
Parkhiです。自称Lean mean transformation queenです。今日はJAIやAIの話はしません - だから金曜日にここにいるのかもしれませんね。私は2つのことをします：1つの質問をして、3つのことについてお話しします。1つ目は私の会社GE Vernovaについて、2つ目はCassandraからKeyspacesへの移行についての話、そして最後は、この6ヶ月に及ぶ大規模データ変換の過程で学んだことについてです。
まず質問です：RDBMSのSQLに詳しい方、または使用している方は何人いらっしゃいますか？かなりいますね。NoSQLを使用している方は何人いますか？Cassandraだけでなく、どんなNoSQLでも構いません？素晴らしいですね。賢明で知識豊富な聴衆の皆さんですね。では、私たちGE Vernovaについて。GE（General Electric）をご存知の方は何人いらっしゃいますか？ほぼ全員ですね。GE Vernova - Verは「緑」を、novaは「新しい」を意味します。私たちが新しいGE Vernovaです。私たちは特定の目的のために作られました。その目的とは何でしょうか？私たちはエネルギー転換のために作られました。
そして、これが結局のところ、この話の本質なのです。ソフトウェア変革についての話ではありますが、それは大きな目標の中のほんの一部です。このスライドでGE Vernova、この新しい目的志向の会社についてもっと知ることができます。すべてを読み上げることはしませんが。私たちには大きなミッションがあり、このミッションには本当の課題があります。その課題とは、世界の電化を進めると同時に、脱炭素化を実現することです。脱炭素化において最も大きな影響を与えられるのがここなのです。今日でも何百万人もの人々が電力のない生活を送っているというのは信じがたいことです。それは貧困から抜け出すチャンスを妨げています。家族と過ごす週末を電力なしで過ごすことを想像してみてください。それを心に留めておけば、このミッションの重大さが分かるはずです。
私たちには今、現在の立場から生まれた真の機会があります。それは、エネルギー転換を推進することです。これは私が日々個人的に感じている責任です。私たちはこれに取り組むために独自のポジションにいます。これは大きな課題ですが、なぜ私たちが独自のポジションにいるのでしょうか？スライドに示されているように、私たちは発電、送電、配電の様々な分野で活動しています。私たちには機器があり、データがあり、産業転換において期待される重要な役割があります。
もちろん、どのように実行するかが重要です。私たちはGE Vernovaのやり方で実行します。私たちは革新を起こします。GEはイノベーションで知られており、顧客のために働きます。Leanは私たちの働き方の基本です。私の話の中で、Leanに関する用語に言及するのをお聞きになるでしょう。話を進めながら、Leanの用語をいくつか覚えていただければと思います。また、私たちはOne Teamとして働きます。GEは大きな会社ですが、One Teamとして働くことが重要です。私の話の中でOne Teamについて言及するのをお聞きになるでしょう。今回は、AWSとProServとの素晴らしい協力体制がありました。
それ以外にも、私たちには説明責任があり、これが最も重要なことです。私たちは脱炭素化に対して責任があり、エネルギー転換に対して責任があります。私はその仕事を非常に真剣に受け止めています。私たちが様々な大規模な変革を進める中で、私の小さな世界での変革の一つがソフトウェアの変革でした。その課題について少し学んでみましょう。Steveが少し前に言及したこの特定の課題は、600テラバイトのデータを移行することでした。多くの方々はもっと多くのデータをお持ちかもしれませんが、重要なのはデータの性質とこの変革が必要なSaaSシステムです。私たちには300のSaaSエンタープライズ顧客がおり、彼らは何千人ものユーザーをシステムに導入しています。全員がライブで使用している中で、データストアをCassandraからKeyspacesに変更する必要があり、それが課題となっています。何千人ものユーザーに対する99.999%の可用性へのコミットメントにおいて、私たちの説明責任が問われています。変革が完璧である必要があります。タイムラインは非常に厳しく、ライブデータの取り込みと何年にもわたる過去のデータを6ヶ月で移行する必要がありました。
このデータはインターネットで生成されるデータとは異なります。このデータは私たちの日常生活に不可欠なものです。タービン、ジェットエンジン、製造工場の設備など、様々な産業機器からセンサーデータが生成され、私たちのストアに取り込まれ、そのデータに対して多くの分析が実行されています。ほぼリアルタイムの洞察が得られ、レポートや可視化が作成され、制御室のオペレーターが定期的にこのデータを使用しています。これらはコスト意識を持ちながら継続する必要があります。これらが、データ移行を試みる際に私たちが直面した課題でした。
では、なぜ正常に動作しているシステムを移行する必要があるのでしょうか？先ほどSteveが説明したように、私たちはメンテナンスの課題に直面していました。Tombstoneの問題があり、テナンシーモデルは共有型で、変更や柔軟な設定が困難でした。ストアの保守に多くの時間を費やさなければならず、お客様のニーズに集中することが難しい状況でした。また、Serverlessの機能を活用したいと考えていました。時々ノイジーネイバーの問題が発生し、データの急増時には、システムを稼働させ続けるために手作業での対応が必要でした。
この取り組みについて説明すると、私たちはLean手法を採用しています。Leanの原則に従って、小規模な実験から始めました。以前にも移行を試みたことがありましたが、課題は稼働中のシステムであることでした。データにアクセスして抽出しようとすると、利用中のお客様に影響やレイテンシーが発生する可能性があり、それは許容できませんでした。そこで、Amazon Keyspacesを使用した小規模な実験から始めることにしました。実稼働中のデータ取り込みから、既存のCassandraとKeyspaces両方にデータを送信するというアイデアでした。また、観測可能性の構築も開始し、Keyspacesはこの点で非常に役立ちました。常時システムの状態を確認でき、コスト分析データも確認できます。
大規模データ移行の実装：アーキテクチャと進捗管理
これから説明する内容の理解を深めるために、アーキテクチャについて少し説明させていただきます。データが最初に入ってくる際、Ingestion Gatewayがあり、そこで旧ストアと新しい環境のKeyspacesストアの両方にデータを送信し始めました。KafkaキューとGoのパイプラインがデータを取り込み、Keyspacesにデータを取り込むためのパイプラインも構築しました。
最初の実験の素晴らしい点は、ほぼ必ず失敗し、そこから多くを学べることです。この最初の実験では、予想外にデータサイズが5倍に増加することが分かりました。なぜこのようなことが起きたのか、頭を悩ませました。マネージドサービスを使用しているため、5倍のデータは書き込みコストも5倍になることを意味します。AWS SMEとProServチームと共に、ホワイトボードに戻って何が起きているのか調査を始めました。分かったことは、私たちのデータはセンサーデータという特殊なもので、量が膨大だということでした。
通常は単純なdouble値を保存しているだけですが、データを特定するためのキーが非常に大きくなります。これは数十年分のデータを持つ可能性があるためです。これが、予期していなかった5倍のストレージ増加の主な原因でした。私たちは作業に戻り、いくつかの選択肢を検討し、さらに小規模な実験を行って試してみました。私たちに適したハッシュアルゴリズムを見つけました。また、データの保存方法を見直し、お客様ごとに異なるデータサイズに対してより良いパフォーマンスを得られるよう最適化を試みました。
小規模な実験で分かったのは、データサイズが5倍に増えることでクエリのパフォーマンスに影響が出るということでした。私たちは様々なハッシュアルゴリズムを検討し、データを再取り込みして新しいライブデータでパフォーマンステストを実施しました。その結果、より良い結果が得られました。 この一連のプロセスを通じて、私と私のチームにとって重要な学びがありましたので、それを共有したいと思います。常に実験から始め、Leanの考え方に従い、そして2つの兆候が出たときのためにプランBを用意しておくことが大切です。一度立ち止まって、深呼吸をして状況を見直すことで、ハッシュのような斬新なソリューションが思い浮かぶかもしれません。
次に私たちが行ったことを見ていきましょう。実際の履歴データ移行のアーキテクチャについて反復的に改善を重ねていきました。というのも、センサーからのデータが入ってきて、私たちのGatewayがAmazon Keyspacesにデータを送信するという、ライブデータの処理については問題が解決していたからです。ライブデータは問題なかったのですが、数十年分の古いデータ、つまり履歴データを移行する必要がありました。厳しい期限があったので、迅速に移行する必要がありました。私たちはProServチームと一緒にホワイトボードに向かい、優れた設計を作り上げていきました。
では、移行計画の詳細を見ていきましょう。ここにCassandraノード、Amazon ECSタスク、AWS Glueジョブがあり、上部にはキャッシュ、いくつかのS3バケット、そしていくつかのLambdaがあります。これから、この履歴データの移行がどのように機能するのかを説明していきます。まず、最大のクラスターの1つである54個のCassandraノードそれぞれにスクリプトをインストールしました。Cassandraノードにスクリプトをインストールすると、Steveが説明したSSTABLEをS3バケットに抽出しました。そしてS3イベントを使用してキューにエントリを作成しました。
すべてのデータには3つのレプリカがありましたが、マネージドサービスであるため、3倍のコストがかかる3回の書き込みは避けたいと考えていました。ProServチームは、キャッシュを持つことができるキューの実装を支援してくれました。Amazon Keyspacesにデータを最初に書き込むときにキャッシュエントリを作成し、他の2つのレプリカは処理されないようにしました。これにより、各ノードに3つのレプリカがある問題を解決できました。Parquetファイルができたら、それらをAmazon Keyspacesに書き込む必要がありました。私たちのデータは、異なる顧客が様々なドメインやアプリケーションに対して異なるサイズのデータを持っているため、かなり分散していることに気づきました。そこで、SSTABLEからParquetファイルに変換する際にメタデータを取得することにしました。このメタデータは後にAWS Glueジョブでの並列処理に大いに役立ちました。AWS Glueは弾力的なので、効果的に並列処理を行うことができました。6ヶ月以内に確実に完了させる必要があったため - 時間は最も貴重な資源ですから - 多くの計算を行いました。
Glueジョブが起動すると、データをAmazon Keyspacesに書き込み、エントリを作成して完了しました。これは、何百万ものGlueジョブが何ヶ月にもわたって並列で実行される、非常に大規模なプロジェクトとなりました。
同じ歴史的な移行についての次の視点をご紹介しますが、これは少し異なる角度からの見方です。300のエンタープライズ顧客を抱えているからこそ、この問題が興味深いものになる理由がお分かりいただけると思います。先ほどの別のアーキテクチャ図でご説明した取り込みゲートウェイが見えます。上部には既存のCassandraデータベース、下部にはAmazon Keyspacesがあります。 最初に、リアルタイムデータをすべてKeyspacesに送信することから始めました。その後、何百万ものGlueジョブを同時に実行して、過去のデータをKeyspacesに移行し始めました。どの顧客のデータ移行が完了したかを追跡し、完了したら、その顧客のクエリ処理をKeyspacesに移行しました。多くの方がStranglerパターンをご存知だと思いますが、これはそのパターンを別の形で解釈し、顧客が気付かないようにシームレスに移行できるようにしたものです。システムを日常的に使用しているユーザーは、自分たちのストアが変更されたことに全く気付きませんでした - パフォーマンスが向上し、より多くのメリットが得られるようになっただけです。
ここで話題を変えて、Lean Daily Managementについてお話ししたいと思います。プロジェクトがこれほど複雑になると、日々どのように管理するかということが、私にとって重要な学びの一つでした。 地理的に離れた複数のチーム、ProServチーム、AWSチームが日々協力して作業を進める中で、非常に確実な日次スケジュールと管理が必要でした。私たちは毎日、これらのタイムゾーンを越えて会議を行い、進捗状況を把握していました。
私たちは多くのデータを収集しました - 私たちの世界ではデータが重要です。毎日、Glueジョブの性能と実行数を確認していました。この作業中に多くのエラスティシティの限界に挑戦し、Keyspacesのモニタリングによって何が起きているのかを詳しく把握することができました。障害やリトライが発生した場合、それらをすべて明確に確認し、必要に応じて方向転換することができました。このような観察可能性があり、実験中に方向転換できる能力があることで、優れた変革が可能になります。この仕組みを止めるのは非常に困難です - 100万のGlueジョブをデバッグするようなものです。まさに干し草の山の中から針を探すようなものです。当時はストレスの多い日々もありましたが、モニタリングと調整のおかげですべてうまくいきました。
当時の面白いエピソードをいくつかご紹介します。ある日、友人と犬と一緒に湖の周りを散歩していたときに、アイルランドのAWSチームから電話がかかってきて、CloudWatchのメトリクスがおかしいと言われました。何も対策を取らなければ、翌月に8,000万ドルの請求が来る可能性があると警告されました - これは本当の話です。開発者の一人がトレースレベルのログを有効にしていたのですが、1時間ほどで問題を解決することができました。8,000万ドルの請求は発生しませんでしたが、優れた観察可能性とパートナーシップがあったからこそ、この状況を乗り越えることができました。
このような変革には多くの曲がり角があり、私たちはチームとしてそれらに取り組みました。AWSとProServから多くの支援を受け、密接に協力して作業を進めました。このカラフルなスライドでご覧いただけるように、多くのチームが関わっていました。問題に直面するたびに、この変革の過程で私たちのデータとそのデータの形状について、本当によく理解することができました。
データの形状が様々に異なっていたため、適切な並列処理を確保するために変換処理でいくつかの異なる対応が必要でした。これに対して様々な調整を行いました。環境の1つでGarbage Collectionの問題に遭遇しましたが、ProServチームが迅速に支援してくれ、様々なGarbage Collectorを試して問題を解決することができました。また、移行の集中期間中に並列実行していたAWS Glueジョブの数は前例のないものだったため、エラスティシティの限界をテストする際にも課題がありました。ProServチームとサポートチームは、これらの期間を乗り越えるために多くの支援をしてくれました。最後の方でジョブが完了する頃には、バグが見つかりましたが、これは開発では当たり前のことで、修正しました。日々のリーン管理によってこれらの問題に対処することができました。残りの作業はSparkジョブで素早く完了し、そして完了となりました。
プロジェクトの成果と学び：One Teamの重要性
この6ヶ月間から多くの学びがありました。LambdaやAWS Glueジョブが暴走して請求額が上がっているという連絡を含め、様々な予期せぬ出来事が起こることを想定し、それらに対処する準備が必要だということを学びました。AWSチームは喜んで支援してくれ、問題解決に役立つ豊富なデータを提供してくれました。私にとって重要だったのは、チームの心理状態を監視することでした。何百万ものジョブの責任を持ち、デバッグを行う開発者として、それはストレスフルな状況でしたが、お互いの信頼関係を築き、常にコミュニケーションを取り続けることで、一つのチームとして機能することができました。
これが私のお気に入りの部分です。この変革を成し遂げたヒーローたちです。会場に来られている方もいらっしゃるかもしれませんが、これが実際に作業を成し遂げた人々です。これが私のチームです。画面に映っている一人一人を代表して、私は今日ここに謙虚な気持ちで立っています。皆さんがご存じないかもしれませんが、ここに映っている人々の半分はGE Vernovaのメンバーで、残りの半分は様々な部門から集まったAWSのメンバーで、一つのチームとしてこれを成し遂げました。大きな変革は真剣な努力なしには実現できません。そしてこれらの人々がその努力を注ぎ込んでくれました。よろしければ、私のチームに大きな拍手をお願いします。
重要な学びをもう一度お話しします。人が重要で、その人々の気持ちが大切です。あるとき、私はお母さんに叱られました - チームの若手エンジニアの一人がHyderabadで作業に没頭していたとき、日々のマネジメントミーティングで彼のお母さんがカメラに映り、息子が食事をしていないと言ったのです。「何をさせているの？」と。彼は仕事が大好きすぎたのです。チャレンジングな問題を解決するのは楽しく、エキサイティングですが、健康に気を配り、一歩引いて、時間通りに食事を取ることが大切です。それが私の学んだことの一つでした。
これで終わりだと思われるかもしれませんが、そうではありませんでした。データの欠損がありました。変換が完了し、検証スクリプトを実行していたとき、一部のデータが欠損していることが分かりました。その時点で私もチームも疲れ果てていて、それに対処する準備ができていませんでした。非常に小さな問題だったので、無視したい誘惑にかられましたが、それはできませんでした - 私たちは産業界で仕事をしているのです。 なぜデータが欠損したのか？そこで私は、この取り組みを強く支持してくれたプロダクトマネジメントチームと協力して、データ欠損の原因を特定することにしました。分かったことは、過去にエッジデバイスの一部にエラーがあり、本来保存すべきでないデータを受信していたということでした。チームが何年も前にその問題を修正するまでデータは保存され続けていましたが、そのデータは残っていました。そのデータはそもそもKeyspacesにコピーされるべきではなかったので、先に進むことができました。一つのチームとして働くということに話を戻すと、プロダクトマネジメントチームが私のためにデータ欠損の原因を見つけようと奔走してくれた仕事ぶりは、一つのチームとして働くことの重要な側面でした。それがなければ、作業が完了し、欠損データがそもそもKeyspacesに入るべきではなかったと分かったときの、チームとしての最後のほっとした安堵感は得られなかったでしょう。
これを発見した時は、本当に嬉しい日でした。 この経験から得られた重要な学びがいくつかありました。早期に検証を始めることが、その中の一つでした。私たちは、本来始めるべきタイミングよりも遅く始めてしまいました。もっと早く始めていれば時間を節約できたのにと常々感じていました。Product Managementチームも、もっと早く始めていれば慌てて物事を探し回る必要はなかったはずです。次回同じようなことをする時は、この経験で時間を失ったので、かなり早めに始めようと思います。
もう一つの重要な学びは、信頼関係の構築です。 Supportチーム、パートナー、Product Management、ステークホルダー、そしてリーダーたちなど、様々な部門やチームと協働する際には、チーム間の信頼関係を築くことが本当に重要です。これは不可欠なことで、時間をかけてしか実現できません。私の祖母がいつも言っていたように、愛と信頼は奪うことはできず、与えられるものだけです。チームの全員から信頼を得るのは、時間をかけてじっくりと進めていくプロセスなのです。
Observabilityは重要です。 ソフトウェアを構築してから、どうモニタリングするかを考えることが多いのですが、初めからObservabilityを組み込んでおくことが重要です。そうすれば、問題を早期に発見できます。この作業の初期段階では、AWSの同僚たちが素晴らしいパートナーとなってくれました。
さて、ゴールラインに到達し、私の話も終わりに近づきました。 私たちはTime Seriesサービスを変革しました。このスライドの最も素晴らしい点は、システムが稼働し続けている間、停止やトラブルが一切なかったことです。すべてのデータを移行し、古いシステムを廃止してコスト削減目標を達成し、Amazon Keyspacesへの移行を成功させました。
移行後、多くのメリットが見つかりました。 スライドにその一部が示されています。このプロジェクトでPoint-in-Time Recoveryを手に入れました。また、柔軟性も得られました。Steveが先ほど話したTime To LiveがAmazon Keyspacesで設定可能になりました。テナンシーのサイロ型モデルにより、様々なエンタープライズ顧客向けにきめ細かな調整ができるようになりました。Amazon Keyspacesを使用することで、スケールを実現しながら、メンテナンスにかける時間を減らし、優れたObservabilityを達成できました。私にとって最高の点は、チームが顧客の要望に集中できるようになったことです。私たちはストアの管理者になりたかったわけではなく、顧客のニーズに合わせてサービスを最適化したかったのです。そして、それが実現できました。
とはいえ、私たちは一つ一つの変革を通じてエネルギートランジションを先導しており、皆さんは今まさにその小さな変革の一つをご覧になりました。最後までお付き合いいただき、ありがとうございます。私が皆さんとランチの間に立ちはだかってしまいましたね。ご清聴ありがとうございました。Yogiさん、プレゼンテーションに参加していただき、ありがとうございます。このように顧客の方々に登壇していただけることを、私たちはとても嬉しく思います。いつの日か、皆さんの中の誰かがこのステージに立つことになるかもしれませんね。質問がございましたら、私たちは外におりますので、お気軽にお声がけください。それ以外は、ランチをお楽しみください。そして若者が言うように、「Likeボタンを押すのを忘れないでください」。セッションに関する皆さまからのフィードバックをお待ちしております。午後も良い一日を。素晴らしいre:Inventをお過ごしください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion