「Snowflake ID」のご紹介: 分散環境で大規模に一意の ID を生成するにはどうすればよいでしょうか?

[[334452]]

画像ソース: unsplash

一意の ID により、開発者はデータ オブジェクトを正しく識別、保存、取得できるようになり、データ オブジェクトが複雑なリレーションシップ スキーマに参加できるようになります。アプリケーション開発サイクル中、プログラマーは常に一意の識別子を生成するというタスクに直面します。

これらの一意の ID はどのように生成されるのでしょうか?さまざまな負荷サイズで最適なアプローチはどれですか?複数のコンピューティング ノードが次に利用可能な ID を競い合う分散環境で、ID が一意性を維持するにはどうすればよいでしょうか。この記事では、小さな単一ノードから Twitter レベルまで、最も一般的な 3 つのテクノロジーを紹介します。

ユニバーサルユニーク識別子 - UUID

ソフトウェアで長年使用されてきた UUID (Universally Unique Identifier) の概念は誰もがよく知っています。これは 128 ビットの数値であり、制御され標準化された方法で生成されると、非常に大きなキー空間を提供でき、衝突の可能性を事実上排除できます。

UUID は、時間、ノードの MAC アドレス、MD5 ハッシュの名前空間など、複数の異なる部分から構成される複合 ID です。これらすべての組み合わせに対応するために、UUID 仕様は長年にわたってバージョン 1 とバージョン 4 などいくつかのバージョンを経て進化してきました。

データとビジネス ドメインによっては、他のバージョンに関心を持つ開発者もいるかもしれません。 128 ビットの数値を扱うことは、情報を記述するのに開発者にとって最も使いやすい方法ではないため、UUID は多くの場合、16 オクテットがハイフンで区切られた 32 の 16 進文字に変換され、合計 36 文字になる標準的なテキスト形式で表されます。

UUID サンプル - バージョン 4

UUID の最も興味深い特性は、個別に生成でき、分散環境でも一意であることが保証されることです。基本的な ID 生成アルゴリズムは複雑ではなく、同期を必要とせず (少なくとも 100 ナノ秒レベルまで)、並列実行できます。

分散環境での一意のIDの生成

一意性を自己生成できるという固有の特性により、UUID は分散環境で最も一般的に使用される ID 生成テクノロジーの 1 つとなっています。ただし、UUID には追加のストレージ スペースが必要になるため、クエリのパフォーマンスに悪影響を与える可能性があります。

永続層によって生成されたID

アプリケーション レベルで一意の ID を生成したくない場合のもう 1 つの一般的なアプローチは、永続ストレージを使用することです。

最近のすべての RDBMS は、開発者が一意の識別子の生成を委任できる何らかの列データ型を提供します。 MongoDB は ObjectID を提供し、MySQL と MariaDB は AUTO_INCREMENT を提供し、MS-SQL-Server は IDENTITY などを提供します。 ID の実際の表現はデータベースの実装によって異なりますが、一意性の意味は同じです。

永続化レイヤーによって生成された ID により、アプリケーション コードで一意の ID を生成する必要があるという問題が軽減されます。しかし、非常にビジーなアプリケーションが前面に置かれた大規模なデータベース クラスターを運用する場合、このアプローチでは不十分な可能性があります。

もう 1 つ問題があります。データベースへのラウンドトリップがなければ、生成された ID はコードに認識されません。

RDBMS とコード生成 ID

上の図では、RDBMS への余分なラウンドトリップによりアプリケーションの速度が低下し、コードが不必要に複雑になる可能性があります。ただし、最新の ORM フレームワークは、使用されている基盤となる RDBMS 製品に関係なく、標準化された方法でこれを実行するのに役立ちます。

ID サーバーまたは Snowflake ID

ID サーバーは、分散インフラストラクチャの一意の ID を生成する役割を担います。 ID サーバーが実行する機能に応じて、ID を作成する単一のサーバーになることもあれば、1 秒あたり大量の ID を作成するサーバーのクラスターになることもあります。

Twitterを紹介する必要はありません。平均すると 1 秒あたり 9,000 件のツイートが生成され、ピーク時には 1 秒あたり 143,199 件のツイートが生成されます。 Twitter では、大規模なサーバー インフラストラクチャ全体に拡張し、効率的なストレージ ID を生成するソリューションが必要でした。

[[334454]]

画像ソース: unsplash

そのため、Twitter は、基本的な保証を備えながら、大規模に一意の ID 番号を生成できる Web サービスである Snowflake を立ち上げました。

Twitter は以前、プロセスごとに 1 秒あたり少なくとも 10,000 個の ID を生成し、応答速度が 2 ミリ秒未満のサーバーを使用していました。 ID サーバー間でネットワーク調整は必要なく、生成される ID はほぼ時系列順に並べられ、ストレージを最小限に抑えるために生成される ID はコンパクトである必要があります。

上記のプロジェクトに対処するために、Twitter は Scala で記述された Thrift サーバーとして Snowflake プロジェクトを開発しました。生成される ID には次のものが含まれます。

時間 - 41 ビット (ミリ秒精度)

設定されたマシンID - 10桁

シリアル番号 - 12 ビット (マシン 1 台あたり 4096 回転ごとに 1 回)

Snowflake プロジェクトは終了し、より広範なプロジェクト TwitterServer に置き換えられましたが、分散 ID ジェネレーターの動作の基本原則は引き続き適用されます。各ジェネレーターは独立しているため、Twitter はクラスターの同期と調整による追加の遅延を発生させることなく、必要に応じてインフラストラクチャを拡張できます。

ID サーバーを使用するソリューションは、コード生成 ID と同様に機能します。

IDサーバーがIDを生成する

ID サーバーへのラウンドトリップによってパフォーマンスは依然として低下しますが、複雑なデータベース操作が伴わないため、この追加の待ち時間はオブジェクトを RDBMS にフラッシュする場合よりもはるかに短くなります。 ID Server は、複雑で遅延を誘発するインフラストラクチャを導入することなく、開発者が一意の ID を生成する方法と場所を制御できるようにする中間ソリューションを提供します。

最終的にデータを保存する必要があるアプリケーションでは、一意の識別子を生成することが必須のステップです。この記事では、UUID (ローカルで生成された ID)、永続層ドライバー ID (集中的に作成された ID)、SnowflakeID (ネットワーク サービスとして生成された ID) という 3 つの一般的なアプローチについて説明します。

万能の解決策は存在しません。アプリケーションで一意の ID を生成する方法を選択するには、データ、永続性オプション、ネットワーク インフラストラクチャを考慮して、ニーズと必要な規模に適したソリューションを見つける必要があります。