元の投稿のマークダウンの方言のため、クロスポストにはいくつかの問題があります。特に、元の投稿に存在する図は示されていません。興味のある方はオリジナルもチェックしてみてください。オリジナルの方がわかりやすいと思います

3週間でイベントソーシングとCQRSアーキテクチャに加えてHBaseをアップグレード

TL; DR

イベントソーシングとCQRSアーキテクチャシステムに加えて、HBaseバージョンのアップグレードに青緑色の導入戦略を使用しました。
展開アプローチは非常にうまく機能し、プロジェクトの目標を達成するのに合計3週間しかかかりませんでした。この経験は私たちにとって新しくてエキサイティングでした。だから私はそれを共有したい:)

データベースのアップグレードについて

データベースのアップグレードは常に面倒であり、本番シナリオでこのような状況に対処するときはいつでも、非常に緊張します（私が扱っている他の本番操作と比較して100倍になると思います） 。

この感覚は、データベース環境の操作の経験や経験がない人と共有するのは難しいです。そして、データベース関連の操作を経験し、苦労したことがあれば、99.9％の人が同意すると思います。リスクが高く、コストもかかりますが、アップグレード自体が製品に新しい価値を提供することを意味するわけではなく、緊急の理由がない限り、多くの場合優先されません。

同時に、データベースが「手に負えなくなる」場合、それは大きな隠れたリスクであり、この問題に対処する方法が話題になっています。多くの開発者やオペレーターがそのような状況に苦しんでいます。

アップグレードアプローチ

一般に、2つの選択肢があります。

ローリングアップグレード

1つはローリングアップグレードです。データベースのバージョンを1つずつ順番にアップグレードします。
ここで良い説明を見つけました。単語に慣れていない場合は、これをお読みください。

ソフトウェア開発におけるローリングアップグレードとはどういう意味ですか？

長所
- データは1か所にあります。したがって、異なるクラスター間でデータを同期する方法や、同期が完全に機能することを保証する方法について考える必要はありません。
短所
- アップグレードが完了すると、元に戻す簡単な方法はありません。したがって、アップグレードによってパフォーマンスの問題が発生した場合、大きな問題が発生します。
- 長時間実行されているデータベースには、テスト環境では再現できない予期しない状態があります。場合によっては、本番環境で問題に対処する必要があります。そして、その可能性はあなたを本当に緊張させます。

青緑色の展開

もう1つは、青緑色の展開です。この場合、アップグレードされたデータベースクラスターを個別にプロビジョニングし、ある時点で新しいデータベースクラスターを使用するようにアプリケーションを切り替える必要があります。
「青緑色の展開」という言葉に慣れていない場合は、このブログ投稿を確認してください。

BlueGreenDeployment

このアプローチはWebアプリケーションの展開で広く使用されていると思いますが、「ルーター」を「アプリケーション」に、「Webサーバー」を「データベース」に置き換えると、同じアプローチをデータベースのアップグレードに適用できます。

長所
- アップグレード中は、実行中の本番データベースに触れないでください。これにより、ローリングアップグレードアプローチと比較して、作業がはるかに簡単になります。
- 予期しない問題が発生した場合は、古いクラスターに簡単に戻すことができます。また、問題が発生した場合にスコープを最小化できるように、リクエストを段階的に分散することもできます（これを行うには、「短所」のように、新しいクラスターから古いクラスターにデータを同期する必要があります）
- 上記の要因により、テスト環境での負荷テストをいくらか短縮でき、プロジェクトを迅速に進めることができます。
短所
- 両方のデータベースクラスター間でデータが同期されていることを確認する必要があります。古いクラスターから新しいクラスターへだけでなく、アップグレード後に簡単に元に戻す方法が必要な場合は、新しいクラスターから古いクラスターへも。しかし、多くの場合、相互のデータ複製は非常に困難です。すべての操作で2つのクラスターに書き込むことができますが、1つのクラスターのみがダウンし、そのクラスターのみへの操作が失敗した場合に備えておく必要があります。その処理は非常に複雑になります。
- 両方のクラスターを実行している間は、2倍のサイズのサーバーが必要です。これにはいくらかの費用がかかり、システムがクラウドインフラストラクチャ上にない場合は困難になる可能性があります。

私たちのアプローチ

基本的に、私たちのアプローチは青緑色の展開です。また、イベントソーシングバスとしてKafkaが前面にあるため、上記の「短所」のデータ同期の問題に対処するのがはるかに簡単でした。

現在のアーキテクチャ

まず、基本的なアーキテクチャを紹介します。ところで、チャットメッセージサブシステム全体を「Falcon」と呼びます。そのため、図には鷹のアイコンが表示されています。

エンドユーザーがチャットメッセージを投稿すると、write-apiはメッセージデータをKafkaに入れます
read-model-updater（略して「rmu」）は、Kafkaからデータをフェッチし、それをread-modelに変換して、HBaseに配置します
エンドユーザーがチャットメッセージを読むとき、read-apiはHBaseからメッセージデータをプルします

この投稿では、なぜCQRSを選択するのかについては説明しません。したがって、詳細を知りたい場合、またはCQRSの概念に精通していない場合は、以下のスライドを確認してください。
Kafka SummitSF2017-KafkaおよびKafkaStreamsを使用した世界規模のスケーラブルで復元力のあるメッセージングサービス
CQRSによる世界規模のスケーラブルで復元力のあるメッセージングサービスと、Akka、Kafka Streams、HBaseを使用したイベントソーシング

データベースのアップグレードフロー

次に、このアーキテクチャに加えてデータベースのアップグレードをどのように行ったかを説明します

ステップ1： 新しいクラスターを準備し、バックアップから初期復元を実行します。

ステップ2： 別のコンシューマー（この図ではrmu2）を準備して、Kafkaから新しいデータベースクラスターにデータを同期します。最初の復元の前から開始して、古いKafkaイベントを再生します。消費者にべき等を実装するようにしてください。つまり、同じイベントが複数回消費された場合でも、システムは適切に機能する必要があります。

ステップ3： 新しいコンシューマー（rmu2）が最新のKafkaメッセージに追いついたら、新しいデータベースクラスターからデータをプルする別のread-apiを準備します。そして、新しいread-apiにリクエストを徐々に送信します。

データの同期が数ミリ秒で終了した場合でも、古いクラスターと新しいクラスターの間には状態の違いがあります。この違いにより小さな問題が発生したため、事前にクラスターとアプリケーションロジックの違いによってどのような問題が発生するかを確認し、評価チェックを実行する必要があります。または、read-apiの前にユーザー属性などに従ってリクエストを配信するための適切なレイヤーがある場合（たとえば、NginxまたはプロキシのようなEnvoyを介したルーティング）、そこに適切なルールを設定するだけで、違いを効率的に処理できます問題にはなりません。

また、このプロジェクトを振り返ってみると、既存のAPIから新しいAPIにリクエストをミラーリングできれば、エンドユーザーに影響を与えることなく本番トラフィックを使用して負荷テストを実行できることがわかりました。

ステップ4： すべてが完全に機能することを確認したら、新しいread-api 100％に切り替えて、古いクラスターとアプリケーションをシャットダウンします。

このアプローチの方が優れていると思う理由

通常の青緑アプローチとの違いを説明しましょう。通常の青緑の問題の1つは、理想的にはアップグレード前だけでなく、アップグレード後も、両方のクラスターでデータが同期されていることを確認する必要があることです。このアプローチでは、データベースが提供するレプリケーション機能を使用する代わりに、データベースの更新は、作成および準備するアプリケーションを介して個別に適用されます。このアプローチには多くのメリットがあります。

まず、これらは別々に機能しているため、各フェーズでデータがどのように同期されるかを気にする必要はありません。特に、アップグレード後に簡単に元に戻す方法が必要な場合は、新しいクラスターから古いクラスターにデータを同期するために、追加の（ほとんどの場合は非常に困難な）作業が必要になります。しかし、このアプローチでは、それらは独立して機能しているだけです。したがって、アップグレード後に予期しない問題が発生し始めた場合に備えて、古いものを使用するように戻すことができます。

次に、古いクラスターと新しいクラスター間のバージョンの互換性について気にする必要はありません。データベースが提供するクラスターデータ同期機能を使用する場合、一部のエッジケースで発生する可能性のあるバージョン制限と互換性の問題が発生します。しかし、このアプローチでは、各データベースにデータを配置する独立したアプリケーションを準備するだけです。ほとんどの場合、もっと簡単に解決できる問題だと思います。また、理論的には、データベースのバージョンを更新するだけでなく、同じアプローチを使用して新しいクラスターを完全に異なるクラスター（DynamoDBなど）に切り替えることもできます。その場合、バックアップデータを初期設定に使用することはできず、初期データ移行プログラムを準備する必要があります。少し時間がかかりますが、それが妥当な項目だと思います。

結論

CQRSとイベントソーシングの主題は、ソフトウェアアーキテクチャでよく議論されます。運用の観点から、イベントバスとしてもう1つのレイヤーを使用すると、インフラストラクチャの複雑さと運用コストが増加します。正直言って、以前はその観点からこのアプローチはあまり好きではありませんでした。しかし、それによってインフラストラクチャの運用方法も変わり、データベース運用の平和がもたらされることに気づきました。はい、私はCQRSとイベントソーシングをとても楽しんでいます:)

次の課題

Kafka（イベントソーシングバス）を何にアップグレードするのか疑問に思われるかもしれません。ええ、それが私たちの次の挑戦になります。通常のローリングアップグレードやブルーグリーン展開よりも優れたアプローチが存在することを願っています。エンジニアの人生は続く！