プロジェクトと設定
ソースファイルと自動化設定は、チーム独自のバージョン管理とバックアップ手順で保持してください。クラウドMac上の作業コピーを唯一のバージョンにしないでください。
技術トラブルシューティングガイド
クラウドMacで問題が起きたら、まず順番に切り分ける
初回接続、macOSの利用、Xcodeビルド、MLX推論、ストレージ拡張、注文に関する問題をまとめて確認できます。該当するチェックを済ませてから、注文ID、発生時刻、機密情報を伏せたログを送れば、サポートチームが重複確認を減らして対応できます。
- サポート範囲
- 6種類の問題
- 販売中の構成
- 3モデル
- サービスノード
- 4ノード
調査の振り分け
まず層を特定し、証拠を集める
チケットを送信
A
接続前
入口
引き渡し状況、ノード、接続情報、ローカルネットワークを確認します。
B
作業中
実行
バージョン、依存関係、ディスク、メモリ、ログを順番に確認します。
C
送信前
証拠
時系列と再現手順を残し、パスワード、秘密鍵、機密情報を削除します。
推奨資料
注文ID + モデル + ノード + 時刻 + マスキング済みログ
問題が起きた工程から確認を始める
6種類の入口を確認できます。現在の状況に最も近いものを選び、接続失敗、ビルドエラー、注文の問題を同じ説明に混在させないでください。
注文前チェック
用途、構成、接続条件を先に明確にする
注文をまだ作成していない場合は、まずこの6項目を確認してください。用途と必要なリソースを明確にするほど、3つの販売構成から選びやすくなり、ストレージ容量、ネットワーク条件、利用期間の選択をマシンの障害と取り違えずに済みます。
ノード一覧
シンガポール、日本（東京）、韓国（ソウル）、香港で3モデルを提供しています。最終的な利用可否はコンソールのリアルタイム表示をご確認ください。
注文準備チェックリスト
6 / 6項目
- 用途を明確にするビルド、テスト、継続的インテグレーション、MLX推論
- モデルを選ぶM4 16GB、M4 24GB、またはM4 Pro 64GB
- ノードを選ぶチームのタイムゾーンとデータ転送経路で判断
- 請求サイクルを確認する日、週、月、四半期単位で注文を確認
- ストレージ要件を確認するシステム、プロジェクト、依存関係キャッシュ、モデルファイルを分けて考える
- リモート接続環境を整えるローカルネットワークが必要な接続を許可し、安定していることを確認
接続できないときは引き渡し状況から確認し、パスワードを何度も変更しない
クラウドMacへの初回接続で問題が起きる原因は、注文状況、接続情報、ローカルネットワーク、入力操作にあることが多いです。以下の順番で確認し、各手順では変更する変数を1つに絞ってください。
-
01
注文
注文が接続可能な状態か確認する
コンソールにログインして現在の注文を確認します。処理中の場合はステータスが更新されるまで待ち、古いスクリーンショットや別の注文の接続情報は使わないでください。
-
02
情報
接続情報を項目ごとに確認する
ノード、ホストアドレス、接続方式、アカウントが同じ注文に紐づいていることを確認します。コピー時は前後の空白を確認し、実際の認証情報をチャット履歴、スクリーンショットのファイル名、公開リポジトリに記録しないでください。
-
03
ネットワーク
ローカルネットワークの制限を切り分ける
ローカルネットワーク、ファイアウォール、プロキシが接続を遮断していないことを確認します。信頼できる別のネットワークで比較テストできますが、アカウント、クライアント、ネットワークを同時に変更しないでください。
-
04
入力
アカウント入力を再確認する
大文字と小文字、見間違えやすい文字を区別し、キーボードレイアウトが想定どおりか確認します。再現する場合はエラーの種類と発生時刻だけを記録し、パスワードそのものは記録しないでください。
Xcodeのビルドエラーはツールチェーンからログまで順に確認する
まず実際にビルドを実行している環境を確認し、その後で依存関係と署名を確認します。すべてのキャッシュを削除したり、Xcodeのバージョンを連続して変更したりすると、元の問題を再現しにくくなります。
-
1
Xcodeのバージョンを固定する
現在選択しているXcodeのパス、バージョン、プロジェクト要件を記録し、コマンドラインのタスクとグラフィカルインターフェースが同じツールチェーンを使っていることを確認します。
-
2
署名ファイルを確認する
必要なファイルがチーム独自のシークレット管理プロセスから注入され、パスと権限が正しいことを確認します。署名ファイルの内容をサポート依頼にコピーしないでください。
-
3
依存関係キャッシュの範囲を絞る
失敗がダウンロード、解析、コンパイル、リンクのどの段階で起きているかを確認します。該当する依存関係のキャッシュだけを削除し、削除前後のログを比較できるように残します。
-
4
ディスク容量を確認する
プロジェクトディレクトリ、ビルド成果物、アーカイブ、依存関係キャッシュの使用量を個別に確認します。容量が不足している場合は、必要な成果物を先にエクスポートしてから再生成できる内容を削除します。
-
5
最小限のログを切り出す
最初のエラー前後にある必要な行、実行コマンド、終了ステータスを残します。トークン、ユーザー名、内部リポジトリのアドレス、署名情報を削除してください。
MLX推論
モデルを読み込めることを確認してからサービスの同時実行を試す
MLX推論の問題では、モデル形式、ユニファイドメモリ、サービスのリッスン設定、リクエスト負荷を分けて確認します。まず1リクエストで再現可能な基準値を作り、同時実行数を段階的に増やしてください。ロード失敗とサービスの過負荷を混同しないことが重要です。
FORMAT
モデル形式
まず確認
モデルファイルが完全で、変換方法が統一されていることを確認し、使用したフレームワークとバージョンを記録します。
MEMORY
ユニファイドメモリ使用量
次に測定
ロード前、ロード後、初回リクエスト後の値を記録し、一時的なピーク値だけを見ないようにします。
LISTEN
サービスのリッスンアドレス
入口を確認
リッスン範囲とポートがアクセス設計に合っていることを確認し、必要なアクセス制御を設定します。
LOAD
リクエストの同時実行数
段階的にテスト
1リクエストから始め、入力を固定したまま同時実行数を段階的に増やし、遅延と失敗の種類を記録します。
LOG
モデルのロードログ
証拠を残す
バージョン、起動パラメータ、エラーの前後関係を残し、業務入力と機密性の高いパスを削除します。
データの役割ごとに容量を計画し、ノードを唯一のバックアップにしない
システム、プロジェクトのソースファイル、依存関係キャッシュ、ビルド成果物、モデルウェイトではライフサイクルが異なります。まず分類してから、ストレージの追加を決めてください。
依存関係とビルドキャッシュ
キャッシュは反復作業を効率化できますが、削除の範囲を設定する必要があります。ディスクの問題を調べるときは、まずディレクトリごとに使用量を集計し、すべてを直接削除しないでください。
モデルとデータファイル
モデルの出所、形式、バージョン、使用容量を記録します。大容量ファイルをアップロードする前にノードのパスを確認し、利用期間終了前のエクスポートに必要な時間を確保してください。
アーカイブと成果物
ビルドアーカイブ、テストレポート、推論出力にはタスク単位の名前を付けます。受け入れ確認が完了したら、保持が必要な内容をチーム管理下のストレージへエクスポートしてください。
注文と更新
注文情報はコンソールの現在のページを基準にする
ログイン後、現在の利用期間、利用可能な更新オプション、選択中のモデル、ノード情報を確認します。ノードは365日継続して稼働します。実際の注文状況と利用可能なオプションは、コンソールのリアルタイム表示をご確認ください。
新しい注文を作成する場合は、3つの販売構成から1つを選び、シンガポール、日本（東京）、韓国（ソウル）、香港の4ノードから目的のノードを確認します。カタログ内の組み合わせはすべて注文できますが、実際の利用可否はコンソールに表示されます。
最初の依頼から調査に必要な情報をそろえる
依頼内容には、どの注文、どのマシン、どのノードで、いつ、どのように再現し、ログに何が表示されたかを記載してください。「接続できない」「ビルドに失敗した」だけでは、通常は原因を特定できません。
注文ID
コンソールに表示される注文IDを記入し、任意のマシン名で代用しないでください。
モデルとノード
VMCache M4 16、VMCache M4 24、またはVMCache M4 Pro 64と、対応するノードを明記します。
発生時刻
タイムゾーンを記載し、継続的、断続的、または一度だけ発生したのかを説明します。
再現手順
既知の正常な状態から、操作、入力の種類、期待される結果、実際の結果を順番に記載します。
影響範囲
単一タスク、単一プロジェクト、すべてのタスクのどれに影響するかを説明し、正常に動作する比較対象も記載します。
マスキング済みログ
エラーの前後関係、バージョン、終了ステータスを残し、パスワード、秘密鍵、トークン、業務データを削除します。
2つの連絡方法
サポートチケットを送信
既存の注文はコンソールにログインしてチケットを送信してください。コンソールに入れない場合や購入前の相談の場合は、次のアドレスへメールを送信できます。 support@vmcache.com。
次のステップ
確認を済ませ、証拠をサポートチームに渡す
新しいリソースが必要な場合は3つの構成を比較し、既存の注文に問題がある場合は、注文ID、ノード、発生時刻、再現手順、マスキング済みログを添えてチケットを送信してください。