高可用性で業務停止を3分の1以下に減らす方法

高可用性（HA）システムの設計という話になるとさ、「俺の書いたコードは絶対に落ちない」なんて自信満々なベテラン、意外といないんだよね。そもそも無理じゃない？　現場を歩いてきた人間なら痛感するリアルがそこにある。ウェブアプリ作ったことがあったり、API公開したり、ときにはバックエンドを鬼のようにスケールさせたり…経験重ねるうち、高可用性って単なるチェックリストにポンと印つければOKってもんじゃなくて - 「考え方そのもの」という感じになってくる。いや正直、そう思わされるよ。

でさ、「HAベストプラクティス」みたいなまとめ記事、世の中いっぱい転がってるけど - 例えば「ロードバランサつけて二箇所ゾーンにデプロイすれば万事解決！」みたいな浅さで終わっちゃってたりして、それ違うだろ？と思いながら読んだ記憶、うーん何度かある。本当にリアルな高可用性と言われたらブラックスワン級の突発的トラブルとか妙な障害とか、とんでもなく一時的にトラフィック爆増した瞬間まで耐え続けるアレを指してるはずなのに……。「そこまで見据えて構えるべし」みたいな深い考えや具体的な方法論が必須になる。それ抜きじゃ語れない気がしてしょうがない。

だからこのガイドでは、小手先だけじゃどうにもならない大事な設計ポイントだけをちゃんと掘り下げてまとめた（多分）。ミッションクリティカルな商用サービスでも、いや個人開発であろうとも、そのまま応用可能 - 要は、本当の意味で“壊れにくい”システム組み上げる道筋について例を交えて示すことで、高可用性へ近づくための包括的指針としている……つもり、なんだけどね。案外こういう地道なの、大事。

で、高可用性が実際そこまで重要視される背景……まぁ以下ざっくばらんに挙げてみようかな。まずサービス停止した瞬間、その顧客ふっと消えちゃう危険は真剣だし、トラブル連発すればブランドや信用なんぞ簡単に崩れてしまう。また予測不能の障害によって夜中・明け方問わず現場担当への鬼電対応依頼が舞い込むパターンも充分あり得て……思わず頭抱える。でもつまり逆説的には、「高可用性」の設計思想そのものこそ、不意打ちリスクへの現実解・運営課題対策としてほぼ不可避なんだ。机上のお飾り理想とは全然違って、ごまかし効かない分野 - まあ、そう腹括っておいたほうが楽になる気さえするよ。

2017年に起きたAmazonのS3障害――正直言うと、あれは業界でも結構な衝撃だったんですよね。13分間で損失は推定1億5,000万ドル。ちょっと想像が追いつかない額…いや、本当に。でも、それだけじゃなくてさ、2022年のSlackのダウンタイムもなかなか印象的だった。あのときは世界各地で一斉に仕事が止まったって話、まだ覚えてる（ため息）。やれやれ。

けど、多くの解説記事なんかを見ていると――まあ何というか、重要な点がさらっと流されてしまうことが多いと思わない？高可用性（HA）って単純に稼働時間を引き伸ばすためだけのものじゃなくて、ユーザーからどれだけ信用されるか、その土台にもなっているわけで……ここ、大事だよ。本当に。ちゃんとシステムに高可用性があると、新しいサービスをリリースするときも「まあ、大丈夫だろう」と心から思えるし、エンジニア側も夜になったら少しくらい安心して休めたりする。不意打ちのアラート？ええ、多少減るんです。そして事業としても混乱せずに成長できる余地が生まれる。それこそ現場感覚かな。

さて、「高可用性」って具体的には何なの、とちょっと考えてみたい。明確化すると、「可用性」はシステムが利用者の期待通り動いている時間比率を意味しているんだよね。この「スリーナイン」（99...）

「9%の稼働率（99%）」だと、ざっくり年間で約8.7時間システムが止まる計算になるんだよね。これが、いわゆる「ファイブナインズ（99.999%）」まで持っていくと…びっくりするぐらいで、その年間ダウンタイムはたったの5分程度なんだよ、うそみたいに短い。でもね、だからといって稼働率さえ高ければ安心かというと…そうも言えない気がする。むしろ、それだけじゃ何とも足りなくて。

## 💡 真の高可用性（HA）を支える4つの柱

1. **冗長性** - 単一障害点（SPOF）が消えている状態にしておくことが第一歩かな。
2. **フォールトトレランス** - 何かトラブルが発生した時でも、その影響範囲をなるべく分離・限定できるよう設計されていること…まあ要は大事な部分まで巻き込まないようにする、という話。

【明確な高可用性アプローチ】
Auto-Recovery――この言葉、意外とさらっと使われるけど、本質を掴むのは案外やっかいだ。システムが障害に直面した瞬間、自動で回復機能を働かせて、サービス停止を避けようとする。そのおかげで「えっ？今何か起きた？」と思う間もなく普通に稼働し続けてしまうので、人によっては「あれ、バグ見落としたかな」と勘違いしそうになる。ま、いいか（笑）。そしてもう一つ、Graceful Degradation。これは、一部機能だけ抑えめにして、全体ストップじゃなくゆるやかな劣化として事態を処理するスタンスだ。急な全面ダウンよりずっと現実的というか…正直助かった経験ある人、多い気がする。

「高可用性（HA）＝ノーリスク」だなんて思わない方が身のためって感じ。むしろ、“測定できる範囲内でどうやってリスクとうまく付き合うか”っていう終わりなき攻防戦なんだよね。この辺り、業務で真剣勝負していると本当に痛感させられる場面が多い。

【Netflix・Meta・Kubernetes 各社の高可用性実践例】
大手テック企業が打ち出す高可用性設計――最近の潮流というか、それぞれ結構個性的だったりする。

1. カオスエンジニアリング（Netflix）：
Netflixの場合、「Chaos Monkey」というあまりにも皮肉なネーミングのツールまで作って、本番環境でサーバーをわざと止めたりしている。「そこまで乱暴なの!?」と驚いたものだけど、本物の障害下でも踏ん張れる耐性――これ抜きでは、到底運営できない領域なのだろう。それにしても現実味あるやり方だと思う。

2. セルベースアーキテクチャ（Meta/Facebook）：
FacebookことMetaは、“セル”単位ごとの独立構造で自社インフラを区切っている。一つ壊れても他は生き残る仕組みになっていて、この“ブラスト半径”（影響範囲）の限定が要とも言えるかな…。何度見ても興味深いやり口だけど、大規模サービスならこれぐらいやるしかない、と個人的には納得してしまった節がある。

Kubernetesって、まあ…どうにも「HA」つまり高可用性が土台から考え抜かれてる感じなんだよね。セルフヒーリングするPodやらローリングアップデート、それに組み込み型サービスディスカバリも揃ってるし。ちょっと面倒くさそうだけど、Stripeみたいなフィンテック企業では、この冗長性の恩恵を最大限に活用しててさ――Google Cloud Platform（GCP）、Amazon Web Services（AWS）、Microsoft Azureとか複数クラウドでKubernetes回してんだよ。ぶっちゃけ普通の情シスには荷が重いかも。

さて、現代的クラウドネイティブeコマース基盤を「高可用設計」で構築しようと思ったら…まず最初に各レイヤごとに障害発生前提の設計方針立てないと詰む。こういうの頭で理解してても実際落とし込むとなると気力吸われがち。

フロントエンドやCDNまわりでは、「API死んでもキャッシュ済レスポンスならブラウザ側Service Worker経由で返せばいいや」といったフェールバック方法が肝心になってくるんだよな…。<br>例えばこんな具合：

self.addEventListener('fetch', event => {

  event.respondWith(

    fetch(event.request).catch(() => caches.match(event.request))

  );

KubernetesのreadinessProbe機能を使うと、Podが「今まさに稼働できる状態か？」を逐一判別してくれるので、ほんとうに“ready”認定されたPodだけにトラフィックが流れる仕組みになる。なんだか安心はするけど…でも、それだけじゃ不安なんだよな（個人的には）。さらに言えば、最近よく耳にするカオステストというやり方――要は意図的に障害を起こすやつだ――これも大事で、たとえば kubectl annotate pod my-app chaos-mesh.org/inject-pod-failure=true みたいなコマンドでPod故障の模擬実験ができたりする。うっかり本番で事故る前に、本当に自動復旧とか回復性ロジックがちゃんと動作するのか…これ実際チェックしたほうがいいと思ってる。

そしてね、支払いプロバイダーなど外部サービス全般が急遽ダウンしちゃった場合、「グレースフル・デグラデーション」って手法が救いになることも。つまり注文内容をいったんキューイングしておいて後で再処理できる設計――地味だけど現場では超重要だった。Pythonだと process_payment(order) 失敗時に queue_order(order) に突っ込んで、その上ユーザー通知まで行うとか、まあ想像つくかな。同じノリでDB死んだ場合はRedis辺りからキャッシュ情報取り出して log_warning で状態を記録、とか地味な工夫も有効なんだわ。正直こういう泥臭さ抜きじゃ運用成り立たない。

パフォーマンス調整について悩む技術者、いや多分皆同じ罠に陥りがちなんだけど…　可用性%、エラー発生率、それからp95/p99レイテンシー指標とかDBレプリケーションラグ（replication lag）、キュー長さらには復旧所要時間など――このあたり、一瞬だけ見て放置しちゃ絶対ダメだった。（意識低い日はスルーしそうになるけど。）Prometheus設定例では db_replication_lag_seconds のようなgauge型メトリクス収集推奨されているんだよね（たしか公式にも載ってた気がする）。

あと、「N+1ルール」と呼ばれるベタな知恵。必要ノード数Nより常時1台余分(N+1)回すことでローリングアップデート中も単体ノード故障時も止まらず済む。「まぁ保険料みたいなものか」って軽視しそうになるけど、本当に効く。一方でサーキットブレーカー＋バルクヘッド構造体（CircuitBreaker cb = CircuitBreaker.ofDefaults("paymentService");）併用して各依存サービスごとコントロール独立させる点は更なる要所と言える。「ある依存先爆死→システム全部巻き込み」が減れば夜中のアラート激減、身にも経験的にも染みる話。

えっと…最後に「ブラック・スワン」のようなどう足掻いても完全には避け難いタイプの災厄への備えも無視できないですね。不測の事態？人類誰にも読めない未来…わかった風振って忘れがちなので、自戒込めて念押ししておくよ。ま、いいか…。

同時にいくつもの障害が巻き起こると、なんだかもう…頭の中が混乱しちゃうけど、それぞれにちゃんとした対策ってやっぱり必要だよね。たとえば「スプリットブレイン（Split brain）」のケースとか—これは昔から嫌なトラブルだけど—データ損失を未然に防ぎたいなら、「クローズド」（つまり敢えて書き込みを拒否する動作）で止めてしまう方針がおすすめ、とされるんだ。ほら、この辺はシステム設計の“賭け”みたいな側面もあったりして、思わずため息出そう…。

またさ、「サンダリングハード」のリトライ問題なんかでは、一斉にアクセス再試行が重なることで今度は負荷が跳ね上がることになる。それを避けたくて指数バックオフとジッター加味のアルゴリズム──たとえば：
ini
wait = base * 2 ** attempt + random.uniform(0, 1)

こういう式を使って待ち時間ばらしたりするの、まあ常識にはなりつつある気がする（いや正直、それでも全部うまく行くかどうか不安になる場面多い…）。

それからDNSやサービスレジストリそのものが落ちてしまった場合についても言及しないわけにはいかないね。この場合はローカルでキャッシュ済みだった情報でフォールバック対応っていう裏技的処理？　困ったときほどこういう臨機応変さって大事なのかな、と思わされたりする。あとリージョン単位で一部だけ壊れている場合にはRoute53ヘルスチェックみたいな仕組みを使って健全な他リージョンへセッション誘導する技術も主流になってきてるよ。

さて、実際によくある“見落としポイント”、ちゃんと言葉にしておきたいんだけど…。まず、状態保持型サービスとかスティッキーセッションへの依存は極力避けるよう推奨されているよね。その代わりとしてRedisなど外部セッションストア活用してAPI自体はできる限りステートレスに保つ努力…地味だけど重要。「ふーむ」と唸っちゃうくらい細かな違いでも結果大違いになっちゃうし…。そしてHTTP以外の基盤サービス（例：DNS、CDN、それに外部API等々）の死角監視も絶対手抜きNGだったなぁ。負荷急増してオートスケール無しだと高可用性なんて無理ゲー状態だから、自動スケーリンググループやサーバーレス技術（Lambda・Fargate等）の併用策こそ現場では普通になっている。……ところで最近、本当に何も設定せず安心できるシステム構成なんて存在しなくなった気がするのだけど、私だけ？

あとは各層ごとのトレーシング（Trace）やアラーティング導入なしじゃ、高可用性システム成立あり得ません！…なんて声高々に叫びたくなる夜もある。でも真剣な話、そのくらい運用保守段階まで先回りした設計意識、大切さしか感じないんだよ、本当に。

少し脱線したけど…2025年以降の話になるけれど、高可用性分野で注目株となっているキーワードはいろいろ湧いてきてる。「AIによる障害予測」や「エッジファースト型・グローバル低遅延ノード」、それからML＆サービスメッシュ生かした“自己修復型インフラ”――この辺、不意打ちみたいに現実味増してきた（笑）。今後の将来像として、多分リアクティブではなくプロアクティブ＝“先回り的運用手法”への転換が決定打になる感触すら漂っていて、時代は確実に新しい方向へ舵切ろうとしている。ま、いいか。

正直、HA（高可用性）について考え込んでいると、単なるシステムの稼働時間では収まらない...なんかもっと大きな「レジリエンス（回復力）」という考え方に行き着く気がしてくる。いや、本当に—二択で「有」か「無」か、みたいに白黒つけられる話じゃなくて、「どこまで備えるか」という賢い意思決定のグラデーション、そのさじ加減を問われてるようなものでさ。失敗することが前提になって設計したり、自動で障害を検知＆リカバリーする仕組み、それからソフトフェイル戦略や、“あーもう予想できん”みたいな混乱（カオス）への覚悟――そういったものたちだって必要不可欠、と言いたい。 うん……まあこれら全部は一気に無理でも、半分くらい取り入れれば、多分かなり上出来のHA設計になると思うよ。本気でフルセット実践できれば…相当効果は出るだろうね。ま、いいか。

なんだかんだで、全部が「火事」になったら呼び出されるようなエンジニアになりたい、って思うんですよね。ま、いいか。

## 🎓 ボーナス：HA面接フラッシュカード

💬 「パフォーマンスの調整？どうやってる？」
→ p95やp99のレイテンシーを意識して最適化したり、負荷が高まった時にはオートスケールを動かすことが多いかな。まあ…状況によって変えるけども。

💬 「エッジケースはどう捌くの？」
→ オーダーならまずキューに積む。それからキャッシュで返せる分はサッと返すし、もし問題があればフェイルグレースフルでとりあえず落ち着かせる感じっすね。曖昧だけど、大体そんな運用。

💬 「追いかけてるメトリクスって何？」
→ 可用性（％とか）、キューの深さ、復旧までの時間、それにレプリケーション遅延とか…そういう指標を監視しつつ動いてます。ま、ときどき見逃しそうになることも正直ある。でも重要だよね。

このガイドって、けっこう気に入った人いるんじゃないかなぁ。チームメンバーにサクッとシェアしておくのも悪くないし、ほら、夜中のPagerDutyで予想外に叩き起こされるその時――なんか「あれ？前準備しててよかった」って自分を褒めちゃうかもしれないよね（笑）。多分、その時になってから思い出して「やっぱり取っといて正解だった…」とホッとするはず。
ま、いいか。