E-MapReduce:OSS および OSS-HDFS のパフォーマンスを最適化するためのベストプラクティス

背景情報

データレイクの普及に伴い、ますます多くのユーザーが OSS を使用してデータを保存しています。 OSS は、99.9999999999%（12 ナイン）のデータ耐久性と 99.995% のサービス可用性を保証できます。 OSS は、ストレージコストを管理および削減するための複数のストレージクラスを提供します。

アプリケーションが OSS にデータを書き込んだり、OSS からデータを読み取ったりする場合、OSS はアプリケーションから送信された 1 秒あたり数千のリクエストを処理できます。 OSS は、各パーティション内のオブジェクトをオブジェクト名のアルファベット順にソートします。 パーティションは、OSS に保存されているオブジェクトのサイズと、オブジェクトにアクセスするために送信されたリクエストの QPS に基づいて分割されます。 各パーティションは、1 秒あたり少なくとも 3,500 件の PUT、COPY、POST、または DELETE リクエストと、5,500 件の GET または HEAD リクエストを処理できます。 設定できるオブジェクトプレフィックスの数に制限はありません。 したがって、複数のオブジェクトプレフィックスを作成して、読み取りまたは書き込みのパフォーマンスを向上させることができます。 たとえば、10 個のオブジェクトプレフィックスを作成して、10 個の異なるパーティションに並行してデータを書き込むことができます。 この方法では、アプリケーションは 1 秒あたり 35,000 件の PUT リクエストを送信して、OSS にデータを書き込むことができます。

JindoFS は、Alibaba Cloud で OSS-HDFS という名前のサービスとしてデプロイされています。 OSS-HDFS は、OSS と緊密に統合されています。 E-MapReduce（EMR）クラスターに JindoFS をデプロイおよび保守することなく、OSS-HDFS を使用できます。 OSS-HDFS の詳細については、「OSS-HDFS とは」をご参照ください。

HTTP リクエストのレイテンシを削減するためのベストプラクティス

OSS バケットまたは OSS-HDFS サービスを ECS インスタンスと同じリージョンにデプロイする

バケットの名前は、OSS ではグローバルに一意です。 バケットを作成するときは、バケットのリージョンを指定する必要があります。 バケットの名前とリージョンは、バケットの作成後に変更することはできません。 ネットワークレイテンシとデータ転送コストを削減するために、バケットと同じリージョンにデプロイされている ECS インスタンスを使用して OSS バケットにアクセスすることをお勧めします。 詳細については、「OSS の内部エンドポイントを使用して ECS インスタンスから OSS リソースにアクセスする」をご参照ください。

ワークロードを水平方向に分散し、同時リクエストを送信してスループットを向上させる

OSS は、大規模な分散ストレージシステムです。 OSS のスループットを最大限に活用するために、OSS に同時リクエストを送信し、複数の OSS サービスノードにリクエストを分散することをお勧めします。 この方法では、ワークロードを複数のネットワークパスに分散できます。

OSS-HDFS は、上記のベストプラクティスをメタデータサービスと共に使用して、ファイルブロックを複数の OSS サーバーに分散し、読み取りおよび書き込みのパフォーマンスを向上させることができます。

アプリケーションが高スループットのデータ転送を必要とする場合は、アプリケーションと ECS インスタンスの仕様に基づいてパラメーターを変更し、複数のスレッドまたはインスタンスを使用して読み取りおよび書き込みリクエストの同時実行性または並列性を制御できます。

• パフォーマンス指標の表示

  CPU とネットワークスループットの要件に基づいて、ECS インスタンスタイプを選択します。 ECS インスタンスタイプの詳細については、「インスタンスの概要」をご参照ください。 また、HTTP 分析ツールを使用して、DNS クエリ時間、レイテンシ、およびデータ転送速度を分析することをお勧めします。

  同時リクエストの数を調整する前に、パフォーマンスメトリックを確認する必要があります。 まず、単一のリクエストによって消費される帯域幅とその他のリソースの使用状況を確認することをお勧めします。 これにより、使用率が最も高いリソースを特定し、リソースの上限に基づいて処理できる同時リクエストの最大数を決定できます。 たとえば、リクエストの処理に 10% の CPU リソースが必要な場合は、最大 10 件の同時リクエストを送信できます。

• 同時実行性と並列性パラメーターの変更

  fs.oss.download.thread.concurrency パラメーターと fs.oss.upload.thread.concurrency パラメーターを変更して、プロセスごとの同時アップロード数と同時ダウンロード数を制御できます。

  MapReduce または Spark ジョブを実行する場合は、次の設定も変更できます。

  • MapReduce ジョブの場合、mapreduce.job.maps Hadoop パラメーターと mapreduce.job.reduces Hadoop パラメーターを変更して、ジョブごとの同時マップタスク数と同時リデュースタスク数を制御できます。

  • Spark ジョブの場合、--num-executors オプションを設定するか、spark.executor.instance Spark パラメーターを構成して、同時実行される executor の数を制御できます。

レイテンシの影響を受けやすいアプリケーションを構成して、タイムアウトリクエストを自動的に再試行する

OSS は、GetService（ListBuckets）、PutBucket、GetBucketLifecycle などの管理関連 API 操作のクエリ/秒（QPS）を調整します。 アプリケーションが同時に多数のリクエストを開始すると、リクエスト調整がトリガーされたことを示す HTTP 503 が返される場合があります。 この場合は、数秒後にリクエストを再試行することをお勧めします。

fs.oss.retry.count パラメーターを変更して、OSS または OSS-HDFS に送信されたリクエストを再試行する試行回数を制御し、fs.oss.retry.interval.millisecond パラメーターを変更して再試行間隔を制御できます。 再試行回数が増えるたびに、間隔は 2 倍になります。 また、fs.oss.timeout.millisecond パラメーターを変更して、ネットワークの状態に基づいてタイムアウト期間を調整することもできます。

頻繁にアクセスされるコンテンツをキャッシュする

アプリケーションと同じリージョンにある静的ファイルにアクセスするために、アプリケーションが多数のリクエストを送信する必要がある場合は、JindoData を使用して静的ファイルをキャッシュできます。 JindoData は、ファイルをブロックとして分散キャッシュサービスに保存できます。 これにより、OSS または OSS-HDFS から同じデータを繰り返し読み取る必要がなくなります。 JindoData は、アクセスレイテンシを効率的に削減し、コンピューティングリソースの利用率を高めることができます。 詳細については、「JindoFSx の透過的なキャッシュ機能を使用して OSS または OSS-HDFS へのアクセスを高速化する」をご参照ください。

最新の JindoSDK バージョンを使用する