ArmMiniはiOSエンジニアとSREで構成されています。私たちは先にプロジェクトを立ち上げてからユーザーを探したわけではありません——2021年にラックへ設置した最初の4台のMac miniは、もともと自分たちのアプリのCIを動かすためのものでした。このページでは、私たちが何者か、なぜ専有物理サーバーにこだわるのか、そして実際にどのように運用されているのかをご説明します。
現在チームは7人:iOSエンジニア3名、SRE 2名、テクニカルサポート2名で、UTC+8とUTC-8の2つのタイムゾーンに分かれています。全員が自分のアプリやCIパイプラインを自社のサーバーで動かしているため、マシンに問題が起きたとき、たいていユーザーより先に私たちがアラートを受け取ります——自分たちのビルドが先に落ちるからです。
この経験が私たちの優先順位を決めています。まずマシンの安定性を確保し、認証情報を素早く届け、問題が起きたら自分たちで再起動できる体制を整える。それが済んでから他のことを考えます。サイトに書かれているトラブルシューティングの手順ひとつ、レイテンシの数字ひとつも、すべて自分たちがこれらのマシンに実際に接続して検証したものであり、ドキュメントからの引用ではありません。
私たちは意図的に小規模を保っています。7人で100台以上のマシンを管理できているのは、残業のおかげではなく、アウトオブバンドの電源制御、自動モニタリング、セルフサービスでの再インストールといった仕組みを一度でしっかり作り込んでいるからです。チケットの初回応答を2時間以内に抑えられているのは、問い合わせの8割がポータル上でユーザー自身によって解決されており、残りだけが人の対応を必要とするからです。
あなたが毎日Xcode、ランナー、シミュレーターと向き合っている人なら、きっと話が合うはずです。具体的な疑問があればトラブルシューティングガイドをご覧いただくか、お気軽にお問い合わせください。
$ system_profiler SPHardwareDataType | grep Chip
Chip: Apple M4 Pro
$ uptime
14:32 up 217 days, load averages: 3.42 2.98 2.71
$ ops team --list
ios-dev x3 sre x2 support x2
coverage: UTC+8 / UTC-8
eating our own dogfood since 2021
all nodes healthy共有型の仮想化なら、1台のホストマシンを8分割すれば利益率はずっと良くなります。私たちはこの道を選びませんでした。理由は3つあり、どれも譲れません。
macOSのライセンス条項では、Apple純正ハードウェア上でシステムを動作させることが求められています。1人に1台の実機Mac miniを提供することが、最もクリーンで監査にも耐えうるコンプライアンス上の選択です。共有型の分割方式はライセンス上つねに灰色領域が残ります。私たちは、あなたのビルド・提出フローをそのような灰色領域の上に成り立たせたくありません。
CIで最も避けたいのは遅さではなく、ばらつきです。物理サーバーにはCPUやディスクI/Oを奪い合う「隣人」がいません。同じプロジェクトを連続してフルビルドしても、所要時間のばらつきは通常3%以内です(私たち自身のプロジェクトでの実測値)。ビルド時間が予測できるからこそ、キューイングやタイムアウトのしきい値も正確に設定できます。
仮想化レイヤーは今なお、MetalとNeural Engineの機能を完全にはサポートできていません。MLX推論、シミュレーターのGPUレンダリング、Final Cutのハードウェアエンコードは、仮想マシン上では動作しないか性能が半減してしまいます。物理サーバーなら何も間に挟まらず、チップが持つ性能をそのまま使えます。
5つの物理拠点、いずれもラックの設計から実際のネジ締めまで、すべて自分たちの手で行っています。各拠点の実情は以下の通りです。
2021年創業時からのデータセンターで、東アジアユーザーのデフォルトの選択肢です。3つのプランをすべて常時提供しており、私たち自身のCIもすべてここで動いています。
2024年に稼働を開始し、北東アジア地域のリモート開発ニーズに対応しています。ソウルノードではBasicとStandardを提供しています。Pro/Maxをご希望の場合は東京またはシリコンバレーをご利用ください。
2023年に稼働を開始。北米チームのCIランナーや、TestFlightへの大容量アップロードなど、大きなアップリンク帯域が必要なシーンに適しています。
Mac miniはそもそもラック搭載を想定した設計ではないため、CNCアルミ合金製の専用トレイを自作しました:1Uに4台を並列搭載し、前面配線で、1台を引き出しても隣のマシンに触れずに交換できます。些細なことに聞こえますが、これが故障機の交換に5分かかるか50分かかるかを左右します。
3つのデータセンターすべてが二重の商用電源+UPS+ディーゼル発電機を備え、ラック内は2系統に分かれたデュアルPDUに接続されています。どちらか一方の電源が落ちても、マシンは何も感じることなく動作を続けます。過去12か月、電源起因のダウンタイムは一度も記録されていません。
各マシンはインテリジェントPDUの独立チャンネルに接続されています。システムが完全にハングした場合でも、誰かがデータセンターに足を運ぶ必要はありません——ポータルで「強制再起動」をクリックすれば、PDU側で電源をオフ・オンし、平均40秒で完了します。深夜3時でも同じです。
マシンは専有されていますが、信頼はスローガンだけでは築けません。以下の4項目は私たちの内部runbookの1ページ目であり、ここに公開して監視を受け入れます。
お渡し直後にすべての認証情報を変更するようご案内しています。マシン内には監視エージェントを一切プリインストールせず、運用用アカウントも残しません。私たちのヘルスモニタリングはネットワーク層と電源層の指標のみを見ています——電源が入っているか、ネットワークが通っているか。マシンの中で何が動いているかは、私たちは知りませんし、知りたいとも思いません。
日常の運用はアウトオブバンド層(電源、ネットワーク、ハードウェア管理)にとどまります。トラブル対応のためにお客様のシステムに入る必要がある場合は、チケット上での明確な許可が必須であり、当直のエンジニア1名のみが操作し、操作記録はすべてチケットに添付されます。許可がない限り、誰もユーザーのマシンに触れません。
ユーザーに影響を与えたインシデントは、72時間以内に事後報告を公開します:根本原因、影響範囲、タイムライン、改善策のすべてを漏らさず記載します。事後報告を書くのは、実際にそのインシデントに対応したエンジニア本人であり、マーケティング用の言い回しで加工することはありません。私たち自身もクライアントの立場に立つことがあるので、ごまかしの事後報告がどう読めるかは身をもって知っています。
マシンのラック撤去またはユーザー解約後7日以内に全ディスクを消去し、記録を発行します。SSD退役時はまずディスク全体を暗号化消去し、その後物理的に破壊し、破壊証明をアーカイブします。あなたのコード署名証明書やプライベートリポジトリの認証情報は、いかなる形でもデータセンター外へ流出しません。
言葉だけでは説得力がないので、検証可能な数字をお示しします。集計方法は以下に記載しており、チケットでどの項目についても質問を歓迎します。
集計方法:2026年7月時点の直近12か月ローリング集計。稼働率は分単位でサンプリングし、1台ごとに算出。お渡し時間は即時発送注文の決済完了から認証情報メール送付までの時間。初回応答はチケット作成から最初の担当者による返信までの時間。
資金調達のストーリーはありません。あるのは、マシンを一台ずつ増やし続けてきた道のりだけです。
自社の2つのアプリのCIを動かすために。最初のマウントトレイは3Dプリンターで作ったもので、今も1台記念に残しています。
友人のチームが半数のマシンを借りてGitHub Actionsのランナーを動かし、3か月間クレームゼロ。これはビジネスになると気づき、本格的に取り組む決意をしました。
セルフサービスでの注文、自動での認証情報配布、ワンクリックの再起動・再インストールがすべて実現し、お渡し時間が手作業の半日から10分以内に短縮されました。
最初は32台、北米チームのCI需要に対応。同時期にCNCアルミ合金マウントトレイを5拠点共通の標準仕様として採用しました。
北東アジアの低遅延カバレッジを補完。すべてのマシンがインテリジェントPDUの独立チャンネルに接続され、「強制再起動」がチケット依頼からユーザーのセルフサービス操作へと変わりました。
3つのプランをすべてM4世代に統一し、稼働マシン数は120台を超えました。旧モデルは順次退役させ、ディスクは破壊プロセスに従って処理しています。
現在採用中です。働き方はリモート・非同期中心で、会議は最小限、まず書いてから動くスタイルです。
5拠点の物理サーバーにおける自動モニタリング、アウトオブバンド制御、お渡しフローの保守を担当します。macOSとネットワークの両方に精通し、深夜のアラートに一人で対応でき、わかりやすい事後報告を書ける方を求めています。
応募方法:メール support@armmini.com 宛に、件名に「SRE応募」と明記してご連絡ください。履歴書よりも、あなたが対応した最も難しいインシデントについて読ませていただきたいです。
チケットに寄せられる接続・ビルド・ネットワークの問題に対応し、繰り返し発生する問題をトラブルシューティングガイドに反映していただきます。自分でアプリをリリースした経験や、self-hosted runnerを設定した経験があり、コマンドラインで語れる方が理想です。
応募方法:メール support@armmini.com 宛に、件名に「テクニカルサポート応募」と明記し、これまで書いたトラブルシューティング記録を添えてご連絡ください。
日単位でレンタル可能、通常10分で認証情報をお届けします。7日以内なら未使用日数分を返金いたします。あなたが負うリスクは、最大でも1日分のレンタル料だけです。