# 40、100、200 Gbpsオリジンを完全なシステムとして計画する | SwissOctet Insights https://swissoctet.com/ja/insights/plan-40-100-200-gbps/ SwissOctet / インサイト / ネットワークエンジニアリング ネットワークエンジニアリング 上級 · 4分で読めます 40、100、または200 Gbpsオリジンを完全なシステムとして計画する 大規模なポートクラスを、高容量配布構成を選択する前に、ストレージ、CPU、同時実行数、運用上の質問に変換します。 SwissOctet編集部 ガイドを保存 リンクをコピー このページの内容 01 ポートをデータ規模に換算する 02 ワーキングセットとキャッシュ動作をモデル化する 03 ストレージを独立して測定する 04 プロセッサとキューの限界を観察する 05 配信アプリケーションを検証する 06 実際のTransit仕様を比較する 07 トラフィックを開放する前に運用を準備する 実践チェックリスト 出典と参考資料 ライブラリに戻る 直接の答え 大きなポートは、アプリケーション、ストレージ、プロセッサ、ネットワーク経路、受信側がそれを活用できる場合にのみ価値があります。ワーキングセットと同時実行性を計画し、各制限段階をベンチマークし、運用上の境界を定義してください。40、100、200 Gbpsのカタログラベルはポートクラスであり、普遍的な転送や可用性の保証ではありません。 01 ポートをデータ規模に換算する 10進単位では、40、100、200 Gbpsは毎秒5、12.5、25 GBのラインレート演算に相当します。これらはプロトコルと実装の影響を受ける前の参考換算値です。周辺設計の規模を示すものであり、測定された速度や、オリジンがその量のアプリケーションコンテンツを配信するという約束ではありません。 配信プロジェクトでは、同時リクエスト数、オブジェクトサイズ、ワーキングセットを見積もってください。人気のある小さなセットを繰り返し配信するサービスは、キャッシュされていないアーカイブをストリーミングするサービスとは異なります。前提を明示してください。これらの前提なしに購入した大きなポートは、ストレージ、アプリケーション、受信側の限界を変えないまま、プロジェクトの継続コストを増やす可能性があります。 記載されたポートクラス 生の10進換算 計画上の意味 40 Gbps オーバーヘッド前で5 GB/秒 コンテンツとアプリケーション経路を測定する 100 Gbps オーバーヘッド前で12.5 GB/秒 ストレージ、同時実行性、処理を検討する 200 Gbps オーバーヘッド前で25 GB/秒 すべての段階と受信容量を検証する 02 ワーキングセットとキャッシュ動作をモデル化する どのコンテンツが頻繁に要求され、どれをオンデマンドでストレージから読み取る必要があるかを特定してください。ウォームキャッシュはコールドスタートでは維持できない結果を生み出すことがあります。プロジェクトにとって重要な場合は両方の条件をテストしてください。データセットは、測定が実際に解決すべき問いに答えるのに十分な大きさと現実性を保ってください。 人気のあるリリースと古いアーカイブを持つ、合法的なソフトウェアダウンロードオリジンを想像してください。リリースの繁忙時間帯と通常のアーカイブアクセスを比較してください。公開、チェックサム生成、バックアップのトラフィックが重なる場合は、それらの容量を確保してください。このオリジナルのシナリオは計画の枠組みを提供するものであり、特定のハードウェアやキャッシュサービスがSwissOctetに含まれることを示すものではありません。 03 ストレージを独立して測定する まず、アプリケーションが実行するストレージ操作を測定してください。大きなファイルのシーケンシャル読み取りと、多数の小さなランダム読み取りでは、異なる限界が明らかになることがあります。fioのドキュメントには、それらのパターンを表すことができるワークロードパラメータが記載されています。システムに適合する制御されたテストファイルと設定を使用し、本番データに対して破壊的なテストを行わないでください。 ストレージレイアウト、データセットサイズ、テスト条件を記録してください。キャッシュされたデータを含むベンチマークは、基盤デバイスからの持続的な読み取りとは同等ではありません。その後、アプリケーションの実際のコンテンツ経路で繰り返してください。容量を増やしても配信速度が自動的に上がるわけではなく、複数のドライブを選択しても特定のアレイレイアウトや測定されたスループットが確立されるわけではありません。 04 プロセッサとキューの限界を観察する 高い転送速度では、アプリケーションのCPU使用と並んで、処理と割り込み処理が重要になる場合があります。Linuxには、ネットワーク作業をキューとプロセッサに分散するための受信側スケーリングと関連メカニズムが記載されています。それらの存在と動作はハードウェアと構成に依存します。すべてのサーバーに汎用的なチューニングレシピを適用するのではなく、これらのドキュメントを使用して測定結果を解釈してください。 システム全体がビジーになる前に、1つのCPU、ワーカー、受信キューがビジーにならないか監視してください。本番サービスが暗号化、圧縮、リクエスト処理を使用する場合は、テストにそれらを含めてください。アイドル時の平均CPU値は、飽和したコンポーネントを隠す可能性があります。一度に1つの要因を変更し、ベースラインを保持して効果を理解できるようにしてください。 05 配信アプリケーションを検証する サーバーは、ネットワークベンチマークでバイトを移動するだけでは不十分です。意図したソフトウェアで、接続、リクエスト解析、認可、コンテンツ読み取り、レスポンス完了を検証してください。Nginxは自身の実装のファイル転送と接続制御について文書化していますが、他のソフトウェアには異なる設定があります。運用する実際のバージョンのドキュメントを読んでください。 現実的な同時実行性をテストし、集約出力だけでなくテール完了時間も観察してください。大きな集約値は、タイムアウトする個々のリクエストと共存する可能性があります。サービスが許容可能な動作を維持する限界を確立し、すべてのコンポーネントを一日中理論上の最大値で実行することを目指すのではなく、運用余裕を残してください。 06 実際のTransit仕様を比較する SwissOctetのTransitファミリーは、異なるプロセッサ、メモリ、ストレージ基盤を記載しながら、国をスイスに保っています。正確なプランを読んでください。Transit 100はSSDストレージを記載していますが、他のTransit基本仕様はNVMeを記載しています。追加ディスクオプションには独自のラベルがあります。ポートクラスに、構成の残りを確認する代わりをさせないでください。 また、実際のサービスで可用性、トラフィック条件、管理責任、リカバリプロセスを確認してください。無制限トラフィックはトラフィックモデルを表すものであり、任意の活動の許可や稼働時間のコミットメントではありません。大容量ワークロードには、小規模なものと同様に、明確な運用条件とコンテンツを配布する権利が必要です。 07 トラフィックを開放する前に運用を準備する 誰がコンテンツを公開し、構成を変更し、オリジンを管理できるかを定義してください。それらのインターフェースを保護し、有用な運用測定値を収集し、過負荷のしきい値を設定してください。アプリケーションが予期しない動作をした場合に、トラフィックを減らすかリリースをロールバックする方法を維持してください。大きなインターフェースは、通常のソフトウェアやアクセスのミスの結果を増幅する可能性があります。 許可された受信側と合意された制限を使用して段階的な演習を実行し、計画されたワークロードに向けて増やしてください。結果、未解決の質問、リソースの余裕をデプロイ記録に保持してください。この証拠が裏付ける場合にのみ、より大きなポートを選択してください。完全で測定された設計は、カタログで利用可能な最大の数値よりも有用です。 行動に移す 実践チェックリスト。 ✓ ポートクラスをペイロード配信として扱わずに換算する。 ✓ キャッシュヒット、コールド読み取り、同時リクエストをモデル化する。 ✓ 無害なテストデータでストレージをベンチマークする。 ✓ CPU、ワーカー、ネットワークキューを観察する。 ✓ 配信アプリケーションと受信側の容量をテストする。 ✓ トラフィックを段階的に導入し、ロールバック手順を保持する。 チェックリストをダウンロード よくある質問 重要な詳細。 最大のポートが常に最も安全な選択ですか？ + いいえ。測定された需要とシステム全体の限界から選択してください。より大きなポートは、不十分なストレージ、プロセッサ、アプリケーション容量を解決しません。 すべてのTransitファミリーがNVMeを使用していますか？ + いいえ。実際のプランを読んでください。Transit 100の基本仕様はSSDを記載していますが、他の基本プランと追加ドライブオプションには独自の説明があります。 キャッシュデータだけでなくコールドデータでもテストするのはなぜですか？ + それらは異なる動作条件を明らかにします。リリース、再起動、ワーキングセットの変化は、ウォームキャッシュのベンチマークでは回避されるストレージアクティビティを生み出す可能性があります。 主要参考文献 出典へ。 これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。 Linuxカーネル: ネットワークスタックでのスケーリング docs.kernel.org fio: ワークロードと測定のドキュメント fio.readthedocs.io Nginx: HTTPコアモジュール nginx.org SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。 知識をつなぐ 関連インフラ。 Transit 40 スイス Transit 100 スイス Transit 200 スイス スレッドを維持 次のフィールドノート。 すべてのガイドを探索 フィールドノート / 01 + ネットワークエンジニアリング 基盤 帯域幅、ポート速度、転送量：全体像を読む プロジェクトが移動するデータ量を見積もり、より大きなポートがネットワークパフォーマンスの一部に過ぎない理由を理解しましょう。 4分で読めます ガイドを読む フィールドノート / 02 + ネットワークエンジニアリング 上級 レイテンシ、同時実行数、スループット測定で転送をサイジングする ペイロード容量、配信ウィンドウ、往復時間を使用して再現可能な転送モデルを構築し、ポートラベルと有用なスループットを混同せずにテストします。 4分で読めます ガイドを読む フィールドノート / 03 + 2日目の運用 応用 有用なインシデント対応につながる監視を構築する アプリケーションの症状、実行可能なアラート、小さな対応プレイブックを接続し、サービスが劣化したときにオペレーターが明確な決定を下せるようにします。 4分で読めます ガイドを読む