Discussing data storage techniques - the milky wayの翻訳です。

2022年11月22日

データ保存技術について議論する - 天の川

ストリーミング、バッチ、キャッシュ、アーカイブ、暗号化-データ管理は非常に複雑に見えるかもしれない。アイスクリーム屋に例えて、その選択肢を説明しよう。

キャッシュとミルクの共通点は？どちらも古くなれば役に立たない。あなたがデータ・エンジニアであろうと、アプリケーション・サイドに重点を置く人であろうと、エンタープライズ・データ・アーキテクチャを設計する際には、データ・クエリのテクニックをよく理解することが重要です。この軽快なブログでは、アイスクリーム・ショップの話をし、ミルクが消費される方法とデータが配信される方法を比較し、アーキテクチャにおけるデータの選択を消化する（駄洒落を意図して）手助けをする。

このブログでは、データ工学の難しい概念を少し簡単にするために、ある種のアナロジーを使っています。この例えが完全に一致することを意図しているわけではありません。

あるアイスクリーム屋さんのお話。新鮮な牛乳を使ったソフトクリーム、普通のフローズンアイスクリーム、そしてヤクミルクを使ったスペシャルアイスクリームだ。アイスクリームの質は、使用する牛乳の質によって決まる。ここでは、アイスクリームの種類による牛乳の使い分けについて紹介しよう（ついでにデータの選び方についても）。

新鮮な牛乳（または新鮮なデータ）の必要性

ソフトクリームは当店の人気商品である。ソフトクリームの味は素晴らしいが、新鮮な牛乳を使うにはコストがかかる。

新鮮な牛乳と同じように、新鮮なデータが必要になるかもしれない。常にデータベースに直接問い合わせを行い、キャッシュを使用しないのであれば、コストとレイテンシの点で割高になる。

データベースには、クエリ・コストを節約するための内部キャッシュがあるかもしれません。しかし、データベースの内部キャッシュはかなり汎用的で、アプリケーションに合わせてカスタマイズすることはできません。例えばPostgreSQL®では、内部キャッシュのバッファサイズはshared_buffer configurationで設定されます。shared_buffer`に多くのメモリを割り当てると、マシンの総メモリの中で他の計算処理に使用できるメモリが少なくなります。

粉ミルク（またはキャッシュデータ）の場合

当店ではソフトクリームが一番の売れ筋ですが、普通のフローズンアイスクリームの方がお手頃なので、そちらも買っていかれます。普通のフローズンアイスクリームを作るのに、粉ミルクを使っているから価格を抑えることができるのです。粉ミルクはそれだけでも安いのですが、きちんとストックしておけるので、酪農場まで往復する回数が少なくて済むのです。

この例えでは、粉ミルクはキャッシュされたデータのようなもので、データベースへの往復を節約できるが、粉ミルクのように賞味期限があるため、最新ではないかもしれない。古くなったキャッシュのデータは、ビジネス上の意思決定には使えない。キャッシュの無効化**は、コンピュータ・サイエンスで2番目に難しい問題であることはよく知られている。

たとえ粉ミルクをストックしておくことができたとしても、私たちは健康的な蓄えを維持するためにときどき出かける必要がある。同じように、キャッシュを更新する良い方法を見つける必要がある。コスト、レイテンシ、パフォーマンスを優先するために、キャッシュ・アサイド、ライト・スルー、ライト・ビハインドなど、さまざまなキャッシュ・テクニックがある。しかし、どの選択にもトレードオフがあり、特効薬はありません。キャッシュ技術に頼ることなく、常に新鮮なデータを消費するソリューションはないだろうか？

ミルクパイプ（またはストリーミングデータ）の場合

アイスクリーム屋は新規顧客を大量に獲得しており、新鮮な牛乳から作るソフトクリームの需要を満たすことができない。主原料である新鮮な牛乳が必要なのは明らかだが、酪農場に行かなくても済むようにするにはどうしたらよいだろうか？一つの方法は、大量の牛乳の在庫を用意しておくことである。これには大きなコストがかかるし、使い切れなかった牛乳が腐敗するリスクもある。もう一つの方法は、新鮮な牛乳を常時供給することである。例えば、乳業会社に牛乳パイプを引いてもらい、それを店に配管してもらう。牛乳は加圧され、より早く配達される。おいしいソフトクリームを作るためには、牛乳を元の形に戻す処理が必要だ。

これはバッチ処理とストリーム処理の選択に似ている。バッチ処理では、指定された時間にデータを収集し、データは通常大きなサイズのファイルである。一方、ストリーム処理では、リアルタイムでデータ処理を行えるように、より少量のデータを継続的に流すことを想定している。

地理的に離れた地域に分散システムがあり、ソース・トランザクション・システムから世界中にある複数のターゲット・データストアにデータを移動させることが目的かもしれない。例えば、PostgreSQL®のようなリレーショナルデータベースからRedis®*のようなキーバリューストアにデータを移動するには、Debezium source connector for PostgreSQLを使用してデータをApache Kafka®に送信し、Redis sink connectorを使用してデータをRedisに取り込むことができます。このアプローチの利点は、ソースシステムに負担をかけることなく、シンクをどんどん追加できることです。

次の図は、Apache Kafkaが真ん中に位置する、このような非連結システムのレイアウト例を示しています。

長期保存のためにミルク（データ）を凍らせる

長期保存が必要な場合は、牛乳の冷凍保存が最適です。また、暑い季節に需要が高まった場合にも、牛乳の供給を保証することができます。同様に、アーカイブ・データもKafkaに長期保存するか、AWS S3にシンクすることで、より手頃なストレージ・オプションを利用することができます。例えば、コンプライアンス上の理由から、ある一定の年数データをアーカイブする必要があるかもしれない。

特殊ミルク（機密データ）の管理

アイスクリーム店では、ヤクのミルクを使ったユニークなアイスクリームを販売している。この種のミルクは酪農場にはなく、アイスクリーム・ショップに保管する余裕もありません。ヤクミルクが必要なときはいつでも、現地で調達し、輸送には細心の注意を払い、無駄なく使い切るようにしている。

同様に、APIトークンのような機密データをキャッシュに保存したり、データパイプラインをプレーンテキストでストリーミングしたりすべきではない。必要なときに、この種のデータは生成され、暗号化されたデータとして送信され、使用される。例えば、Apache Kafkaでは、ソースコネクタがメッセージを生成した後、Kafkaに書き込まれる前に、インバウンドメッセージを変換するSMT（Single Message Transformations）をメッセージに適用することができます。このトピックについては、私の同僚であるFrancesco Tisiotのan excellent talkをチェックしてください。また、Apache Flink®を使って、センシティブなデータをリアルタイムでフィルタリングしたり変換したりすることもできます。

コストとパフォーマンスのトレードオフ

最初のうちは、データが少なくて単純なユースケースであれば、PostgreSQLのようなリレーショナルデータベースで十分です。キャッシュやストリーミング・ソリューションを心配するのはやり過ぎのように思えるかもしれません。アーキテクチャをシンプルに保つことは重要ですが、将来のスケーリングニーズを考慮して設計することは不可欠です。データ量とシステムの複雑さが増すにつれて、複数のシステムが互いに会話することは、エンジニアリングの労力とコストに負担をかけることになる。また、データを消費する前にデータを変換する仕組みも必要になるかもしれない。コストとパフォーマンスのトレードオフを決定する際に従うべき3つのルールを紹介しよう：

• ソフトウェア・ソリューションの実際のコストには、現在の実装コストと、将来のメンテナンスおよび近代化コストが含まれます。成熟したシステムの修正コストは高く、しばしば不可能である。
• オープンソースのソリューションは、プロプライエタリなソリューションに比べて、より多くの制御、可視性、および移行の容易さを提供します。
• ストレージやネットワーキング層にボトルネックがあるアプリケーションに、最高のパフォーマンスを期待することはできない。

まとめ

アイスクリーム・ショップには事欠かないが、それぞれに異なる要件がある。あなたのアイスクリーム（アプリケーション）を最高の品質にしたければ、高品質のミルク（データ）と適切なミルクの保存と配信（データベース／ストリーミング）技術を使うことだ。アイスクリームのような～～データ関連サービスを提供する、堅牢でオープンソースのデータ・プラットフォームなら、Aivenを試してみてください。