SW BBANG J

「インスタンスは起動しているのに、ASGが勝手に終了させる」——この現象に直面したとき、最初に疑うべきはヘルスチェックの設定だ。EC2タイプのヘルスチェックはインスタンスの 存在 しか見ていない。アプリケーションがクラッシュしていても、OSが起動していれば「正常」と判断される。Auto Scaling Groupのヘルスチェック設定を正しく理解することは、不要なインスタンス終了を防ぐだけでなく、本当に異常なインスタンスを確実に置き換えるためにも不可欠だ。 TL;DR — ヘルスチェックタイプの選択基準 状況 推奨タイプ 理由 ELBを使用していない EC2 ELBタイプはロードバランサーなしでは機能しない ELBを使用、アプリ死活監視が必要 ELB アプリレイヤーの応答をヘルスチェックに反映できる ELBを使用、インスタンス起動直後に終了される ELB + ウォームアップ期間の確認 ヘルスチェックグレースピリオドの設定ミスが原因のことが多い カスタムアプリ監視が必要 EC2 + カスタムスクリプト ASGのカスタムヘルスチェックAPIで外部から不健全マークを付与 Auto Scaling Groupのヘルスチェックの仕組み ASGのヘルスチェックを理解するには、 誰が ヘルス状態を判定するのかを明確にする必要がある。ASG自身がインスタンスをポーリングするわけではない。ASGは複数のソースからヘルス情報を受け取り、それを元に終了・置換の判断を行う。 graph LR EC2SVC["EC2サービス システムステータス監視"] -->|"Impaired / Stopped"| ASG["Auto Scaling Group ヘルス判定エンジン"] TG["ターゲットグループ アプリHTTPチェック"] -->|"Unhealthy"| ASG CUSTOM["外部スクリプト SetInstanceHealth API"] --...

新しいサービスを立ち上げるとき、DynamoDBのキャパシティモード選択で迷うのはよくある話だ。トラフィックパターンが読めない段階でプロビジョニングモードを選ぶと、スロットリングで障害を起こすか、過剰なコストを払うかのどちらかになる。この記事では、 DynamoDBキャパシティモード の仕組みと、実際の運用判断基準を具体的に解説する。 TL;DR：DynamoDBキャパシティモード選択早見表 判断軸 オンデマンド プロビジョニング トラフィック予測可能性 不明・不規則 安定・予測可能 スロットリングリスク 低い（自動スケール） 設定次第で高い コスト特性 リクエスト単価が高い 安定負荷なら割安 Auto Scaling併用 不要（組み込み） 推奨（必須に近い） 切り替え頻度制限 24時間に1回まで 同左 向いているフェーズ 開発・ローンチ初期・突発トラフィック 成熟サービス・高スループット安定期 DynamoDBキャパシティモードの仕組みを理解する DynamoDBのスループットは、読み込みキャパシティユニット（RCU）と書き込みキャパシティユニット（WCU）という単位で管理される。1 RCUは最大4KBのアイテムに対する強整合性読み込み1回、1 WCUは最大1KBのアイテムへの書き込み1回に対応する。この前提を押さえた上で、2つのモードの動作を見ていく。 graph LR Client["クライアント"] --> Request["リクエスト"] Request --> ModeCheck{"キャパシティモード？"} ModeCheck -->|"オンデマンド"| OnDemand["自動キャパシティ割り当て （PAY_PER_REQUEST）"] ModeCheck -->|"プロビジョニング"| Provisioned["事前設定RCU/WCU"] OnDem...