Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。原文(投稿日:2016/12/14)へのリンクNetflixは,メタデータのキャッシュを目的としてJavaで開発された汎用キャッシュのHallowを発表した。キャッシュは,データを集中的なストアに格納することでネットワークの遅延や帯域といった制限を克服するという,頻繁に使用されるテクニックである。頻繁に使用されるデータをローカルにキャッシュし,使用頻度の低いデータをデータストアに格納するようなデータのキャッシングを実現しようとして,開発者が苦労していることは少なくない。アクセスするすべてのデータをキャッシュするのであれば,実装ははるかに単純になる。Hollowは,データを複数のサーバに分散するのではなく,すべてのデータを各コンシューマに公開するアプローチを採用することによって,データ堅牢性のためのレプリケーションアルゴリズムの必要性を回避している。Object)として格納していたため,それがサイズ上の制限につながっていた。それに代えてHollowでは,固定長のコンパクトな,厳密に型指定されたエンコーディングをデータ表現として使用する。Koszewnik氏から,詳細を聞くことができた。NetflixでもEVCacheを開発して,多大なメリットを享受しています。Hollowで解決しようとしたキャッシュデータのサイズに関わる問題にも,ある程度は対応しています。一方でHollowは,特にサーバ群全体にわたってデータセット全体をレプリケーション可能な場合には,いくつかの問題をmemcachedよりも効率よく解決できます。私たちは,そのようなことの可能な状況が,ほとんどのエンジニアが思っていたよりも広範にあることに気付きました。メモリ上のデータセットの任意の部分に対するO(1)アクセスを確保しながら,データセットを圧縮する手段がHollowである,と考えて頂ければよいと思います。memcachedの最大のメリットは,多数のインスタンスにわたってメモリをプールする分散型キャッシュシステムであることです。集中型であるHollowは,真の分散キャッシュシステムではないと言えるかも知れません。散在型キャッシュシステムと言った方がよいでしょう。分散(distributed)に対して,ここで散在(disseminated)という言葉を選んだのは,データセット全体のコピーが各コンシューマに複製されるという意味からです。Hollowは,スループットの極めて高いキャッシュという,Netflixの要求を満たすために開発されました。Hollowの設計判断のほとんどは,根本的にこのニーズから生じています。すべてのコンシューマに全データセットを複製するということは,ネットワーク越しにデータを取得する必要がないということですので,データセットのどの部分にアクセスする場合でも,レイテンシは無視できるレベルになります。同時にHollowは,データセット全体にわたって,任意のデータをアクセスするために必要なCPUコストの削減を非常に重視しています。memcachedのように緩やかに型付けされたキー/バリューストアと比較した場合,厳密に型付けされた構造化データモデルを要求することによって,アクセスコストの問題への対処を一度行なえば,多くの異なるユースケースでそれが再利用されます。強く型付けされたシステムの構築を選択したことを受けて,データ構造を持つことのメリットを活用した,さまざまなツールを開発しました。データモデルが分かっているため,2つの状態における変更内容を正確に通知することが可能になりました。この情報を表現する目的で,有用性と汎用性の高いUI要素をいくつか開発しています。構造化された方法でデータを完全にローカル保持するメリットのひとつは,データモデル設計時にデータの使われ方を正確に予測する必要がないことです。事前定義されたキーでのみクエリが可能だからです。Hollowでは,データを使用するチームがアクセスパターンを自由に設計できますから,プロデューサチームの作業が開発のボトルネックになることはありません。アクセスパターンとデータモデリングを切り離したことで,プロデューサ側が先入観で決めたインデックスを構築するのではなく,コンシューマによるインデクスの生成が可能になりました。データは読み取り専用,プロデューサは単一,コンシューマは複数です。S3やNFS,さらにはFTPサーバでも可能です。コンシューマは起動時に,データストアにある最新のスナップショット全体を読み取って,データセットをメモリ内にブートストラップします。データセットは差分を適用することで,常にメモリ内で最新に保たれます。コンシューマが再起動した場合には,ブロブストアから再取得しなくてはなりません。スナップショットブロブファイルのフォーマットは実際には単純で,メモリ上のレイアウトとほぼ同じ構造です。従って初期化は,ブロブの内容を直接メモリにコピーする処理が中心で,短時間で実行可能です。これによって,初期化時間を短くしているのです。Hollowは古典的な意味での分散データストアではないので,このようなケースでのCAP定理については,少し違う見方をしなくてはなりません。Tolerance)の面で優れている反面,一貫性については妥協している,と言ってもよいでしょう。初期化されてしまえば,環境に関する問題の影響を受けることはないのです。そもそも分断という概念がありません。データはコンシューマ上にすべて存在するか,そうではないかのどちらかなのです。一貫性については,さらに興味深いものがあります。Hollowのデータセット変更のタイムラインは,個別のデータ状態に分割される必要があります。それぞれが,ある特定の時間におけるデータの完全なスナップショットになるのです。このようなデータ状態が定期的に,通常は数分間隔で生成されます。データセットの伝搬遅延という面では,ある程度の許容範囲が必要になります。この問題を軽減する方法としては,例えばオーバーライドとして,緊急性の高い更新を独立したチャネルで送信することなどが可能です。そのとおり,Hollowが中心的に扱うのは,小規模ないし中規模のデータセットです。TBやPBではなく,MBないしGBが目安になります。Hollowには規模が大き過ぎるとしてデータセットを除外する前に,JSONベースのドキュメントストアをアプローチとして検討してみてください。この方法であれば,1テラバイトをHollowに格納した場合の容量がはるかに小さくなります。Hollowの効率に優れたストレージと十分に調整されたデータモデルを組み合わせることで,巨大なデータセットを中規模にすることが可能になります。10倍あるいは20倍になっても動作するように設計する必要があります。100xのためのソリューションが,必ずしもxに最適であるとは限りません。ここでは,このルールを適用します。データセットの拡大に対してHollowでは,ヒープ使用量を詳細に分析するツールを提供することで,最適化対象の特定を可能にしています。このような指標を時間を掛けて比較することが,潜在的な問題の早期発見には有効なのです。急激な直線的増加に対処する必要のある場合には,最適化の不十分なデータモデルの指標として,あるいは説明できない新たな成長軸の存在を示すものとして,この情報を利用できます。ここではデータモデリングが極めて重要になります。データ構成の方法は,Hollowがデータセットの重複を排除し,圧縮を実現する上で大きく影響します。一般的な圧縮アルゴリズムがハフマンツリーによってデータ内のパターンを見つけ出すのに対して,Hollowではデータモデル内のレコード構造を使ってパターンを特定します。これにはある程度の事前情報が必要になりますが,Hollowが高度な圧縮を実現して,高スループットのランダムアクセスを維持する上では重要な部分なのです。圧縮アルゴリズムについてもう少し教えてください。Hollowは重複排除やエンコーディング,パッキングなど,さまざまな方法で圧縮を実現することで,Javaオブジェクトのオーバーヘッドを克服しています。重複排除の方法と範囲はおもにZenoから引き継いでいますが,POJOから離れることがなければ,エンコーディングやパッキング,そしてもちろんオブジェクトのオーバーヘッドの排除は適わなかったでしょう。パフォーマンスに着目すると,Hollowのデータセットにアクセスする時のCPUへの影響の最小化と,そのデータを表現する上で必要なヒープ容量の最小化を両立する方法が必要でした。最終的に,固定長のビット整列型データ表現にたどり着いたのです。すべてのレコードにおいて,各フィールドは,正確にその最大値を表現するために必要なビット数のみを使用します。access)などのテクニックを使用しています。現時点ではリトルエンディアンと,アンアラインド読み込みに対するペナルティのない(あるいは無視できる)ことが前提となっています。将来的に移植性を向上するためには,こういった最適化を選択可能にすることを考える必要があります。Javaに関連して,2つの疑問があります。実装に(Go言語などではなく)Javaを使用すると決めた理由は何ですか?Java以外のアプリケーションでもHollowを利用可能でしょうか?Koszewnik:Javaを使用することにしたのは,ビデオのメタデータを扱う直接的なコンシューマシステムがJavaベースの言語で開発されていたからです。Javaベース以外の言語からは,今のところHollowのメリットを直接的に利用することはできません。いいえ,Hollowでは,生成されたブロブを実際にプロデューサからコンシューマに分配する上で,インフラストラクチャの提供や特定はしてはいません。S3/DynamoDBベースのインフラストラクチャのプラグインを使って,実運用レベルに拡張可能なサンプルプロジェクトの構築を実習します。PublisherやAnnouncer,HollowBlobRetriever,HollowAnnouncementWatcherといったこれらのサンプルを,他のインフラストラクチャへの実装のガイドとして使用するのは,それほど難しいことではありません。ベンチマークについては,データモデルによってさまざまな結果が出るため,提供を避けてきました。その結果が,いずれの方向に対しても誤解を招きかねないからです。POJOと比較した場合のトレードオフが,Hollowのレコードからデータをアクセスするという非常にわずかなペナルティと,ヒープフットプリントの削減という大きなメリットであると言えば十分でしょう。個人的に取り組んでみたいことはいくつかありますが,プロジェクトが最大の改善を実現できる活動をする上では,特にユーザビリティに関して,コミュニティによる広い視点からのフィードバックを期待しています。Hollowの利用方法については,githubサイトに詳細な情報がある。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。