シンガポール
サービスエリア:東南アジア
シンガポールおよび周辺の東南アジア向け業務経路に適しています。オーストラリアのチームがアジアのコードリポジトリや成果物サービスにアクセスする場合の候補ノードにもなります。
DplyMiniでは現在、シンガポール、東京、ソウル、香港、米国西部の5つのノードを提供しています。各ノードは他のテナントと計算リソースを共有しない専有物理マシンで、仮想マシンではありません。
販売中の2種類の構成はすべてのノードで利用できます。DeployMini M4 16はM4、16GB RAM、256GB SSD、DeployMini M4 24はM4、24GB RAM、512GB SSDです。カタログ内の組み合わせは共通して注文でき、利用可否はコンソールのリアルタイム情報に基づきます。
星図は注文可能なノード間の地理的分布のみを示します。米国西部を架空の複数都市に分けたり、遅延テストの発信都市を販売中のリージョンとして扱ったりはしません。5つのノードはカタログ上同等であり、選択はカードの並びではなくワークフローに基づいて行ってください。
接続線は、チームの入口、コードリポジトリ、署名サービス、成果物ストレージ、エンドユーザーを同時に考慮してリージョンを選ぶ必要があることを示します。専用線のトポロジーや固定ルートを示すものではありません。
各運用票には、カバーに適した方向、販売中の2種類の構成、注文ページへの入口を掲載しています。ここでの「適している」は経路計画の提案であり、実際のオフィスネットワークからのテストに代わるものではありません。
サービスエリア:東南アジア
シンガポールおよび周辺の東南アジア向け業務経路に適しています。オーストラリアのチームがアジアのコードリポジトリや成果物サービスにアクセスする場合の候補ノードにもなります。
サービスエリア:東アジア
日本の開発チーム、日本向けのテスト経路、東京周辺のコードリポジトリ、署名サービス、成果物ストレージに近い場所で継続ビルドを行うタスクに適しています。
サービスエリア:北東アジア
韓国のチーム、北東アジア向けのインタラクティブなデスクトップ作業、ソウル周辺のネットワークでビルド・テスト・成果物転送を行うプロジェクトに適しています。
サービスエリア:華南・東南アジア
華南と東南アジア間の協業経路に適しています。チーム、リポジトリ、成果物サービスが異なるリージョンに分散している場合は、上り回線の安定性とリージョン間ルートを併せて確認してください。
サービスエリア:北米西海岸
北米西海岸のチーム、北米向けの成果物経路、コードリポジトリ・自動化サービス・最終テストユーザーが主に北米にあるプロジェクトに適しています。
中央値は通常時の往復時間、P95は遅いサンプルの状況を示します。表の各セルは「中央値 / P95」の順で、単位はすべてミリ秒です。ソウル、上海、シドニー、フランクフルト、ロサンゼルスはテスト発信都市であり、販売中の追加ノードではありません。
| テスト発信都市 | シンガポール 中央値 / P95 |
日本(東京) 中央値 / P95 |
韓国(ソウル) 中央値 / P95 |
香港 中央値 / P95 |
米国西部 中央値 / P95 |
|---|---|---|---|---|---|
| ソウル | 68 / 92 ms | 34 / 49 ms | 8 / 14 ms | 42 / 61 ms | 136 / 168 ms |
| 上海 | 62 / 91 ms | 48 / 76 ms | 51 / 79 ms | 31 / 55 ms | 149 / 188 ms |
| シドニー | 95 / 127 ms | 121 / 151 ms | 134 / 169 ms | 112 / 145 ms | 146 / 178 ms |
| フランクフルト | 164 / 198 ms | 236 / 279 ms | 221 / 261 ms | 194 / 232 ms | 151 / 182 ms |
| ロサンゼルス | 178 / 216 ms | 112 / 142 ms | 127 / 158 ms | 151 / 185 ms | 26 / 39 ms |
インタラクティブなグラフィックデスクトップではジッターとP95が重要です。バックグラウンドビルドでは、コード取得、依存関係のダウンロード、成果物アップロードの継続的なスループットを重視します。
チームからノードまでが速くても、ノードからリポジトリや成果物ストレージまで速いとは限りません。導入前に入口と外部依存先を個別にテストしてください。
接続ネットワーク、混雑、出口ルート、テスト時間帯によって結果は変わります。自社のオフィスネットワークから再度確認してください。
テストは2026年8月22日に実施しました。各「発信都市 → 注文可能なノード」の組み合わせで、64バイトのICMPリクエストを100回送信し、成功した応答サンプルの往復時間を記録して中央値とP95を算出しています。
発信元には現地の商用ブロードバンドまたは固定回線のIPv4パブリック出口を使用し、VPN、プロキシ、回線高速化は利用していません。異なる司法管轄区域にまたがる経路は越境テストとして扱い、現地都市から同一地域のノードへの経路は越境経路として扱っていません。
結果はテスト時間帯と対応する発信ネットワークを示すもので、固定的な遅延を保証するものではありません。実際のプロジェクトではDNS、TLS接続、リポジトリの応答、オブジェクトストレージのスループット、ファイルサイズ、同時実行数などの影響も受けます。
1回のpingで分かるのはごく限られたことだけです。注文前に、チームの入口、コード、署名、成果物、エンドユーザーを1本の経路として整理し、全体がより安定するノードを選びましょう。
グラフィックデスクトップを頻繁に操作する場合は、開発者からノードへのP95、ジッター、夜間ピーク時の性能を優先して確認してください。バックグラウンドビルドのみなら、インタラクティブな遅延の重要度を下げられます。
完全クローン、差分取得、サブモジュールへのアクセスを比較してください。大規模リポジトリの効率は、単発のpingだけでなく、継続的なスループットと小さなファイルの往復に大きく左右されます。
アーカイブと署名の処理には複数回のネットワークリクエストが含まれる場合があります。対象ノードで証明書ツール、時刻同期、必要なサービスへの実際の接続性を確認してください。
IPA、シンボルファイル、動画、モデルファイルではアップロードスループットがより重要です。実際のサイズに近い匿名化ファイルでテストし、極端に小さいサンプルだけで判断しないでください。
特定市場向けのページ、API、メディア検証を含むタスクでは、エンジニアの所在地だけでなくエンドユーザーの地域もノード選択に含めてください。
まずチームからノードへのP95を比較し、その後ノードからリポジトリと署名サービスへの接続を確認します。
まずノードからリポジトリ、依存関係の取得元、成果物ストレージへの継続的なスループットを比較します。
まずデータ転送量を見積もり、そのうえでノード、利用期間、追加ストレージの組み合わせを判断します。
以下の入口から同じ構成フローに進み、対応するリージョンがあらかじめ選択されます。機種、期間、追加ストレージはご自身で確認してください。利用可否はコンソールのリアルタイム情報に基づきます。
2種類の専有物理マシン構成は5つのノードすべてで利用でき、日単位、週単位、月単位、四半期単位でレンタルできます。料金はすべて米ドル(USD)で決済されます。