ベスト・プラクティス
サーバーレス・インスタンスをプロビジョニングおよび管理する際、および Spark アプリケーションを実行する際には、以下の一連の推奨ガイドラインを使用してください。
| ベスト・プラクティス | 説明 | 参照リンク |
|---|---|---|
| 開発環境と実稼働環境には別個の IBM Analytics Engine サービス・インスタンスを使用してください。 | これは一般的なベスト・プラクティスです。 異なる環境用に個別の IBM Analytics Engine インスタンスを作成することで、実動インスタンスに適用する前に構成およびコードの変更をテストできます。 | NA |
| Sparkの最新バージョンへのアップグレード | オープン・ソースの Spark バージョンはリリースされると、内部テストに必要な時間間隔の後に IBM Analytics Engine で使用可能になります。 「リリース・ノート」セクションの新しい Spark バージョンの発表に注意し、インスタンスのランタイムをアップグレードしてアプリケーションを最新の Spark ランタイムに移行してください。 古いランタイムは非推奨になり、最終的には新しいバージョンがリリースされると削除されます。 実動インスタンスを変更する前に、必ず新しいランタイムでアプリケーションをテストしてください。 | |
| 役割ベースのアクセス権限の付与 | 要件に基づいて、 IBM Analytics Engine インスタンス上のすべてのユーザーに役割ベースのアクセス権限を付与する必要があります。 例えば、アプリケーションを実行依頼する権限を持つのは自動化チームのみにする必要があります。これは、アプリケーションがシークレットにアクセスでき、 DevOps チームがすべてのアプリケーションとその状態のリストのみを表示できるためです。 | |
| 適切な IBM Cloud Object Storage 構成を選択する |
-ディザスタリカバリ（DR）回復力：IBM Cloud Object Storageを使用する必要があります。地域内の複数の異なる都市にまたがってデータをバックアップする地域横断的な弾力性オプション。 対照的に、地域の回復力オプションは、単一のデータ・センターでデータをバックアップします。
|
|
| 外部 Hive メタストアのプライベート・エンドポイントを使用する | Spark SQL を使用していて、 IBM Cloud Databases for PostgreSQL を Hive メタストアとして使用するなどの外部メタストアを使用する場合、パフォーマンスとコスト節約のために、データベース接続にプライベート・エンドポイントを使用する必要があります。 | |
| リソース過剰使用でのアプリケーションの実行 | 各 Analytics Engine サーバーレス・インスタンスには、割り当て量が関連付けられています。 アプリケーションがインスタンス上でサブミットされると、インスタンス割り当て量からリソースが割り振られます。 アプリケーションが使用可能な割り当て量を超えるリソースを要求した場合、アプリケーションは開始されないか、要求されたリソースよりも少ないリソースで実行されます。これにより、アプリケーションの実行速度が予想より遅くなったり、場合によってはアプリケーションで障害が発生したりする可能性があります。 常にインスタンスの現在のリソース使用量をモニターして、アプリケーションが所定の制限内で快適に実行されていることを確認する必要があります。 必要に応じて、サポート・チケットを使用して制限を調整できます。 | |
| リソースの静的割り振りと自動スケーリングの比較 | アプリケーションを実行依頼するときに、実行プログラムの数を事前に指定する (静的割り振り) か、自動スケーリング・オプション (動的割り振り) を使用することができます。 静的割り振りと自動スケーリングのどちらを使用するかを決定する前に、適切な構成を見つけるために、静的と自動スケーリングの両方を使用して異なるデータ・セットを変更することにより、いくつかのベンチマーク・テストを実行することをお勧めします。 一般的な考慮事項: -アプリケーションに必要なリソース (コアおよびメモリー) の数が分かっていて、アプリケーションの実行段階によって異なることがない場合は、パフォーマンスを向上させるために静的リソースを割り振ることをお勧めします。 -リソース使用率を最適化する場合は、アプリケーションの実際の要求に基づいて executor の自動スケーリングを選択できます。 アプリケーションで自動スケーリングを使用するときには、関連するわずかな遅延が発生する可能性があることに注意してください。 |
|
| フォワード・ロギングの有効化および微調整 | -サービス・インスタンスのフォワード・ロギングを有効にして、アプリケーションのトラブルシューティング、進行状況の表示、出力の表示に役立てることができます。 ログ転送では、 IBM Log Analysis インスタンスで転送または保存されたログの数量に基づいてコストが発生することに注意してください。 ユース・ケースとニーズに基づいて、最適な設定を決定する必要があります。 -デフォルト API を使用してログ転送を有効にすると、ドライバー・ログのみが有効になります。 例えば、executor にのみ表示されるエラーがある場合など、executor ログも必要な場合は、ロギングをカスタマイズして executor ロギングも有効にする必要があります。 実行プログラムのログは非常に大きくなる可能性があるため、ロギング・インスタンスに転送されるログの量を最適化するためのオプションと、トラブルシューティングの目的でログに記録される情報の量を最適化するためのオプションのバランスを取ります。 -適切な構成および検索手法を選択する際には、 IBM Log Analysis のベスト・プラクティスに従ってください。 例えば、コストを節約するために、 IBM Cloud Object Storage へのログのアーカイブを使用した 7 日間の検索用に IBM Log Analysis インスタンス・プランを構成することができます。 また、 IBM Log Analysis の資料で、キーワードやポイント・イン・タイムなどに基づいて関心のあるログを検索するための手法を参照してください。 |
|
| サービス・インスタンスのカスタマイズ | -サービス・インスタンスをカスタマイズして、プリインストールされていない Python または conda パッケージを取り込んだり、Spark アプリケーションで使用できるようにするいくつかのファイル (証明書または構成ファイル) を取り込んだりすることが必要になる場合があります。 必要に応じて、ライブラリー・セットを使用してインスタンスをカスタマイズし、アプリケーションのサブミット時にこれらのライブラリー・セットを使用します。 -ライブラリー・セットのサイズは、アプリケーションの起動時間と実行プログラムの起動時間 (アプリケーションを自動スケーリングする場合) に影響します。 また、ライブラリー・セットのサイズには上限 (2 GB) があることにも注意してください。 そのため、異なるアプリケーションが異なるライブラリー・セットを必要とする場合は、アプリケーションの実行依頼時に個別に指定できるように、別々のライブラリー・セットを使用することをお勧めします。 -カスタマイズは、アプリケーション詳細パラメーターで取り込むことができないファイルを取り込むためにのみ使用してください。 Spark アプリケーションを実行依頼するためのパラメーター を参照してください。 files、 jars、 packages 、および pyFiles オプションなど、標準の
spark-submit 同等のパラメーター・オプションを使用する必要があります (ユース・ケースに適合する場合)。 これらのカテゴリーのいずれにも適合しないファイル (自己署名証明書、 JAAS 構成ファイル、 .so ファイルなど) が必要な場合にのみ、「ファイル・ダウンロードのカスタマイズ」オプションを使用してください。 |
|
| アプリケーションのリストを取得するときにフィルターを適用する | UI で、または API または CLI を使用して、アプリケーションのリストを取得する必要がある場合は、適切なフィルターを適用し、必要なセットを取得することをお勧めします。 | |
| 機能をサポートするために他のサービスまたはツールを使用する | IBM Log Analysis および IBM Cloud Object Storage のインスタンスを使用するほか、ユース・ケースによっては、他のサポート・ツールやサービスを使用することもできます。 例えば、(お客様が管理する) Apache Airflow を使用して、アプリケーションのオーケストレーション、スケジューリング、および自動化を行うことができます。 また、アプリケーションをサブミットする前に、 IBM Secrets Manager を使用してアプリケーションに必要なシークレットを保管し、自動化スクリプトを使用して Secrets Manager からシークレットを読み取ることもできます。 また、アプリケーション内から直接、 Secrets Manager から必要なシークレットを読み取るために必要なトークンを渡すことで、アプリケーションの引数を使用してクリエイティブにすることもできます。 | |
| バックアップおよび災害復旧のために代替リージョンのインスタンスを使用する | 現在、 IBM Analytics Engine サーバーレス・インスタンスは、ダラス (us-south) とフランクフルト (eu-de) の 2 つのリージョンで作成できます。 データが配置されているのと同じリージョンにインスタンスを作成することをお勧めしますが、1 次インスタンスが使用不可または使用不可になった場合に備えて、1 次インスタンスと同じ構成のセットを使用して代替リージョンにバックアップ・インスタンスを作成すると常に役立ちます。
自動化では、必要に応じて 2 つの領域間でアプリケーションの実行依頼を切り替えることができるようにする必要があります。 |
NA |
| アプリケーション・ファイル、データ・ファイル、およびホーム・インスタンスに個別のバケットおよびサービス資格情報を使用する | 「関心の分離」原則を使用して、異なるリソース間のアクセスを区別します。 -データまたはアプリケーション・ファイルをホーム・インスタンス・バケットに保管しない。 -データ・ファイルとアプリケーション・ファイルに別々のバケットを使用する。 -アプリケーション・ファイルのバケットおよびデータを含むバケットへのアクセスが制限された別個のアクセス資格情報 (IAM キー・ベース) を使用します。 |
|
| アプリケーションは 72 時間以内に実行する必要があります | アプリケーションまたはカーネルを実行できる時間数には制限があります。 セキュリティーおよびコンプライアンスのパッチ適用の場合、72 時間を超えて実行されたすべてのランタイムが停止されます。 大きなアプリケーションがある場合は、72 時間以内に実行される小さなチャンクにアプリケーションを分割します。 Spark ストリーミング・アプリケーションを実行している場合は、チェックポイントを構成し、アプリケーションが停止している場合にアプリケーションを再始動するためのモニターが適切に配置されていることを確認してください。 | |
| Spark ヒストリーの開始と停止 (必要な場合のみ) | Spark ヒストリー・サーバーを使用する必要がなくなった場合は、必ず停止してください。 Spark ヒストリー・サーバーは、その状態が開始されている間、CPU とメモリーのリソースを継続的に消費することに注意してください。 |