テクニカルガイド
AIクラウドアーキテクチャ
AI クラウド アーキテクチャは、コンピューティング、ストレージ、ネットワーキング、モデル、アプリケーション サービスを AI ワークロード用のオペレーティング システムに編成します。
このガイドを聴くAIによるナレーション · ~2 min
概要
設計は、タスクの信頼性、データ、レイテンシ、コストの制約を満たす必要があります。強力なアクセラレータは、その設計の 1 つのコンポーネントにすぎません。
主なポイント
- ワークロードを運用上のニーズに応じて分離します。
- データと権限の境界を強制します。
- 容量、再試行、ロールバックを一緒に設計します。
ディープダイブ
要件が異なる場合は、対話型ワークロードとバックグラウンド ワークロードを分離します。応答を待っているユーザーには制限された応答時間が必要ですが、バッチ処理ではキューや長時間実行されるジョブが使用される可能性があります。キューのステータスと再試行動作を監視可能にします。データ境界とアクセス役割を定義します。ドキュメント、埋め込み、モデル アーティファクト、ログには、異なる保持要件と許可要件がある場合があります。資格情報を適切な秘密管理に保ち、ネットワークの場所だけで認可が確立されると想定することは避けてください。容量の変更と依存関係の障害に備えて計画を立てます。自動スケーリングには時間がかかり、モデルの読み込みにコストがかかる場合があり、プロバイダーがレート制限を課す場合があります。アドミッション コントロール、バックプレッシャー、制限付き再試行を使用し、使用できない状態をクリアして、1 つの過負荷な依存関係がサービス全体を圧倒するのを防ぎます。デプロイメントのバージョンを管理し、リカバリーをテストします。互換性のあるモデルと前処理バージョン、データ移行、ロールバック手順を確認します。ストレージ、転送、失敗した試行、アイドル状態のリソースなど、有用な完了済みタスクごとのコストを測定します。 1 つの API 呼び出しの料金が安いと、全体のワークフローがより高価になる可能性があります。
04作業例
増幅の再試行を回避する
100 人のアプリケーション ワーカーが 1 つのレート制限モデル エンドポイントを呼び出していると想像してください。失敗した各リクエストはすぐに 5 回再試行されます。
追加の試行により、エンドポイントの容量は追加されずに負荷が増加します。
プロバイダーのバックオフを尊重する制限付き再試行ポリシーを適用し、同時リクエストを制限し、キューまたは使用不可の状態をユーザーに表示します。
それが示すもの
この構築された例は、アーキテクチャが過負荷の拡散をどのように防ぐことができるかを説明します。
現実世界の実装
ステータスが表示され、安全に再試行できるドキュメント処理には、耐久性のあるキューを使用します。
モデル処理能力を通常の Web リクエスト処理から分離します。
実践する
なぜそれが重要なのか
- 費用と予算. アーキテクチャの決定により、パフォーマンスと運用コストが何年にもわたって推進されます。
- より明確な判決. 技術教育は、チームが最新のスタックだけでなく、適切なスタックを選択するのに役立ちます。
- 品質管理. より良いエンジニアリングの選択により、本番環境での信頼性に関するインシデントが減少します。
気をつけてください
- 1 つのベンチマークを最適化すると、より広範なシステムの弱点が隠れる可能性があります。
- インフラストラクチャとメンテナンスのコストは過小評価されがちです。
- システムが複雑になるにつれて、セキュリティと可観測性のギャップが拡大する可能性があります。
次のステップ
- 実装前にレイテンシ、品質、コストの目標を定義します。
- 現実的な負荷とデータ条件でのベンチマーク。
- エラー、ドリフト、ユーザーへの影響を計測器で監視します。
- スケーリングの前に、ロールバックとインシデント対応のパスを準備します。
出典とさらなる参考文献
- Google CloudMLOps アーキテクチャと自動化
探検を続けましょう
よくある質問
自動スケーリングによりレート制限は排除されますか?
いいえ。ダウンストリーム サービスは、実行するアプリケーション インスタンスの数に関係なく、独自の制限を保持する場合があります。