このページには、接続・ビルド・ネットワークという最も多い3種類の問題に対する診断コマンドをまとめています。実際のところ、チケットの約80%は10分以内に自己解決できています。残りについても、障害系チケットの初回応答は2時間以内です。
有人サポートの窓口は、コンソールのチケットとメールの2つだけです。どちらも当直エンジニアが直接対応するため、定型対応のオペレーターへの取り次ぎは発生しません。
対象:インスタンス障害、返金申請、移行予約など、具体的なマシンに関するあらゆる問題。手順:コンソールにログイン → チケット → 新規作成。対応の経緯はすべて記録され、状態が変わるとメールで自動通知されます。
初回応答 ≤ 2時間
対象:コンソールにログインできない場合、アカウントのセキュリティ問題、請求書や商談関連。support@armmini.com宛にメールし、本文に登録メールアドレスとインスタンスIDを明記していただくと、やり取りを1往復減らせます。
初回応答 ≤ 8時間
| 重要度 | 典型的なケース | チケット初回応答 | 進捗更新 | 推奨窓口 |
|---|---|---|---|---|
| P1 | インスタンスへの到達不能 / ノード規模の障害 | ≤ 30分 | 60分ごと | コンソールチケット |
| P2 | 一部機能の不具合(例:VNCは使えるがSSHが通らない) | ≤ 2時間 | 4時間ごと | コンソールチケット |
| P3 | 利用に関する相談、設定サポート | ≤ 4時間 | 対応状況に応じて | チケットまたはメール |
| P4 | ご意見・ご要望、商談・提携 | ≤ 24時間 | 対応状況に応じて | メール |
サポートチームはUTC+8とUTC-8の2つのタイムゾーンでシフトを組んでおり、SLAは実時間で計算され、週末や祝日も同様に適用されます。重要度は影響範囲に応じて当社が判定するため、チケット内でお客様自身が指定する必要はありません。
再起動、再インストール、認証情報のリセットは、いずれも人手を介さずに実行できます。コンソールの電源操作はアウトオブバンド経路で行われるため、システムが完全にフリーズしていても効果があります。これは専有物理マシンならではのメリットです。
手順:コンソール → インスタンス → 電源 → 再起動。マシン全体を一度シャットダウンして再度電源を入れる方式で、約90秒で復旧します。ディスク上のデータには影響しませんが、保存していない作業内容は失われます。VNCの画面が真っ黒になる場合やシステムが応答しない場合の第一の対処法です。
手順:コンソール → インスタンス → システム → 再インストール。バージョン一覧から対象のmacOSを選択できます。再インストールはディスク全体を消去する処理で、25〜40分で完了し、新しいVNC/SSHの認証情報はメールで送付されます。各課金サイクルにつき1回まで無料で実行できます。
手順:コンソール → インスタンス → アクセス → VNCパスワードをリセット。即時反映され、新しいパスワードはページ上に一度だけ表示されるので、その場で必ず保存してください。パスワードを忘れた場合、漏洩の疑いがある場合、またはマシンを引き渡す場合に使用します。SSHや機内データには影響しません。
手順:コンソール → インスタンス → アクセス → SSH公開鍵。新しい公開鍵を貼り付けると60秒以内にauthorized_keysに書き込まれます。同時に古い鍵を無効化するオプションも選択できます。ed25519とRSA(3072ビット以上)に対応し、1インスタンスにつき最大5件まで保持できます。
手順通りに進めれば、各ステップで確認可能な出力が得られます。最後まで進めても解決しない場合は、最後のステップのコマンド出力をそのままチケットに貼り付けてください。中断した箇所からそのまま対応を引き継げます。
症状:VNCクライアント上は「接続済み」と表示されるが、画面が完全に真っ黒、またはグレー画面のまま停止し、マウス・キーボードが反応しない。
$ sudo launchctl list | grep -i screensharing
$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -console
Done.
$ sudo pmset -a displaysleep 0 sleep 0症状:sshが長時間応答せずOperation timed outとなる、あるいは即座にPermission deniedが返ってくる。
sudo pfctl -dで一時的にルールを無効化してから修正してください。$ ping -c 5 <インスタンスのパブリックIP>
$ chmod 600 ~/.ssh/id_ed25519
$ ssh -vvv -o ConnectTimeout=10 dev@<インスタンスのパブリックIP>
$ sudo pfctl -sr | grep 22症状:CI上でxcodebuildがerrSecInternalComponentやUser interaction is not allowedを返すが、ローカルのGUIビルドでは正常に動作する。
$ security unlock-keychain -p "$KEYCHAIN_PASS" ~/Library/Keychains/login.keychain-db
$ security set-key-partition-list -S apple-tool:,apple: -s -k "$KEYCHAIN_PASS" ~/Library/Keychains/login.keychain-db
$ security find-identity -v -p codesigning
1 valid identities foundランナーのインストーラーは、ご利用のCIプラットフォームのランナー設定ページからarm64 macOS版をダウンロードしてください。以下のコマンドはインスタンスのSSHセッション上で実行します。
$ mkdir ~/actions-runner && cd ~/actions-runner
$ tar xzf actions-runner-osx-arm64.tar.gz
$ ./config.sh --url <リポジトリまたは組織のURL> --token <登録トークン> --labels self-hosted,macos,arm64
$ ./svc.sh install && ./svc.sh start
√ runner service startedrun.shをフォアグラウンドで動かすのではなく、svc.shでlaunchdサービスとして登録してください。接続が切れても自動再接続し、インスタンス再起動後も自動起動するため、別途の常駐スクリプトは不要です。登録トークンの有効期限は1時間のみなので、期限切れの場合は再発行してください。
$ brew install gitlab-runner
$ gitlab-runner register --executor shell --url <お使いのGitLabのURL> --token <認証トークン> --tag-list macos,xcode,arm64
$ brew services start gitlab-runner
Successfully started `gitlab-runner`executorはshellを選択してください。ビルドがmacOSのユーザーセッション上で直接実行されるため、Xcodeのツールチェーンやシミュレーターに完全にアクセスできます。並行数は1に保つことを推奨します。Apple Siliconでは1ジョブがすべてのパフォーマンスコアを占有できるため、2ジョブでコアを奪い合うより高速です。
CI用の証明書をログインキーチェーンに混在させないでください。独立したbuild.keychainを作成し、タイムアウトを21600秒(6時間)に設定し、各ジョブの先頭で一度unlockを実行すれば、署名ダイアログの問題は根本から解消されます。
xcodebuildに-derivedDataPathを渡し、ジョブの外にある固定ディレクトリを指定してください。専有物理マシンではキャッシュがジョブをまたいでディスク上に常駐するため、大規模なSwiftプロジェクトの差分ビルドはフルビルドより40〜70%高速になります。
xcrun simctl createでよく使う機種のシミュレーターを事前に作成し、常駐させておいてください。UIテストではシミュレーターのコールドスタートをスキップでき、1ジョブあたり通常60〜90秒短縮できます。インスタンスは回収されないため、一度作成すれば長期間有効です。
$ security create-keychain -p "$PASS" build.keychain
$ security set-keychain-settings -lut 21600 build.keychain
$ security unlock-keychain -p "$PASS" build.keychain
$ xcodebuild -scheme App -derivedDataPath ~/ci-cache/DerivedData build5つのノードにはそれぞれ、業務用インスタンスと同じラック出口を持つ計測用アドレスが用意されています。これを計測することは、お使いのインスタンスを計測することと同義です。各地からの実測レイテンシは「接続方法」ページのノード遅延表をご参照ください。
| ノード | 計測用アドレス | データセンター地域 | 説明 |
|---|---|---|---|
| 東京 | ping.tyo.armmini.com | 東アジア | 東京インスタンスと同じ出口経路のため、実際の体感速度を代表できます |
| ソウル | ping.icn.armmini.com | 北東アジア | ソウルインスタンスと同じ出口経路 |
| シリコンバレー | ping.sjc.armmini.com | 北米西海岸 | シリコンバレーインスタンスと同じ出口経路 |
$ ping -c 20 ping.tyo.armmini.com
20 packets transmitted, 20 received, 0% loss
$ mtr -rwzbc 100 ping.tyo.armmini.com > mtr-report.txt
-r レポートモード -c 100 で100パケットをサンプリング、所要時間は約2分mtr -rwzbc 100を実行し、レポートを保存する。データセンター出口側の問題は当日中に対応します。跨ネットワークの中間経路でのパケットロスについては、上流事業者と経路ごとに突き合わせて確認する必要があり、特定までに通常1〜2営業日かかります。対応状況はチケット上で随時更新されます。
すべてのノードは年間365日連続稼働しており、お客様側で予約・調整が必要となるようなサービス中断はありません。ノード側のハードウェア交換は待機機への切り替えによって完了し、お客様の利用時間を消費しません。実際に障害が発生した場合の対応フローは以下の通りで、全過程を確認いただけます。
監視アラートが発報し、当直のSREが対応を開始します。5ノードすべて24時間365日体制で有人監視しています。
影響範囲を確認し、影響を受けるお客様に最初の障害通知メールを送信します(症状、範囲、復旧見込み時間を明記)。
復旧まで60分ごとにメールで進捗を更新します。「サイレント修正」は行いません。
月間99.5%の稼働保証に基づいて障害時間を算出し、補償対象となる利用時間は自動的にアカウントへ反映されます。申請の必要はありません。
ポストモーテムレポートを公開します(根本原因、詳細なタイムライン、改善項目を記載)。メールで送付するとともに、コンソールのお知らせにも掲載します。
補償の具体的な段階と適用除外条項(不可抗力、お客様自身の操作によるもの)については、利用規約第5章をご覧ください。もし障害を検知したにもかかわらず当社からの通知メールを受け取っていない場合は、そのままP1チケットを送信してください。お客様の監視記録に基づき確認いたします。
ノードの変更、他社サービスやローカルMacからArmMiniへの移行の際には、エンジニアによる1対1の無料サポートをご利用いただけます。対応範囲と境界は以下の通りです。予約の前にご確認ください。
$ rsync -avzP --exclude 'Library/Caches' -e ssh ~/work/ dev@<新インスタンスIP>:~/work/
-P で再開転送に対応、東京→ソウル間の同区間実測で約45~80MB/s
sent 182.4G speedup is 1.31最後のステップのコマンド出力をそのままチケットに貼り付けてください。当直エンジニアがその中断点から直接対応を引き継ぎます。障害系チケットの初回応答は2時間以内で、週末や祝日も同様に適用されます。