SW BBANG J

RDSのスロークエリログを眺めていると、同じSELECT文が毎秒何十回も実行されているのに気づくことがある。商品カタログ、ユーザープロファイル、設定値など、更新頻度が低いのに読み取り頻度が高いデータがRDSを圧迫しているケースだ。ElastiCache Redisをキャッシュ層として導入することで、そのような読み取りクエリの大半をデータベースに到達させずに処理できる。 TL;DR：ElastiCache Redis導入の判断基準 観点 内容 主な用途 読み取り頻度が高く、更新頻度が低いデータのキャッシュ 効果が出やすいパターン 同一クエリの繰り返し実行、セッション管理、ランキング集計 効果が薄いパターン 書き込み主体のワークロード、データが常に変化するケース 主要な構成要素 レプリケーショングループ、プライマリエンドポイント、リーダーエンドポイント キャッシュ戦略 Cache-Aside（Lazy Loading）が最も一般的 注意点 キャッシュ無効化（TTL設計）とコールドスタート対策が必要 ElastiCache Redisの仕組みとアーキテクチャ ElastiCache for Redisは、AWSが管理するインメモリデータストアだ。RDSへのクエリがキャッシュ層でヒットすれば、ディスクI/Oもネットワークラウンドトリップも発生しない。レイテンシはミリ秒単位からサブミリ秒単位に短縮される。 クラスターモード無効（Cluster Mode Disabled）構成では、1つのプライマリノードと最大5つのリードレプリカで構成されるレプリケーショングループを作成する。プライマリエンドポイントへの書き込みは非同期でレプリカに伝播し、リーダーエンドポイントはラウンドロビンでリードレプリカに読み取りを分散する。 graph LR App["アプリケーション"] --> Redis["ElastiCache Redis リーダーエンドポイント"] Redis -->|"キャッシュヒット"...

DynamoDBで『このアイテムを注文日でも検索したい』と思った瞬間、テーブル設計を見直す羽目になった経験は少なくないはずだ。プライマリキー以外の属性でクエリを実行したいとき、LSI（ローカルセカンダリインデックス）とGSI（グローバルセカンダリインデックス）のどちらを選ぶかは、後から変更できない制約も絡むため、設計段階での判断が特に重要になる。 TL;DR: LSI vs GSI 早見表 項目 LSI（ローカルセカンダリインデックス） GSI（グローバルセカンダリインデックス） パーティションキー ベーステーブルと同一 任意の属性を指定可能 ソートキー 異なる属性を指定 任意の属性を指定可能（省略可） 作成タイミング テーブル作成時のみ テーブル作成後でも追加可能 整合性モデル 強整合性読み取り可能 結果整合性のみ ストレージ制限 パーティションあたり10GB上限 制限なし（テーブル全体と同様） スループット ベーステーブルと共有 独立したキャパシティ設定が可能 テーブルあたりの上限 最大5個 最大20個（デフォルト） DynamoDB セカンダリインデックスの仕組み DynamoDBのセカンダリインデックスは、ベーステーブルのデータを別のキースキーマで参照できるようにした、内部的には独立したデータ構造だ。インデックスへの書き込みはDynamoDBが自動的に管理する非同期プロセスで、ベーステーブルへの書き込みが成功した後にインデックスへ反映される。LSIの場合はこの反映が同一パーティション内で行われるため強整合性読み取りをサポートできるが、GSIは非同期レプリケーションのため結果整合性のみとなる。 インデックスに射影（Projection）する属性の選択も重要だ。 KEYS_ONLY 、 INCLUDE 、 ALL の3種類があり、射影する属性が多いほどストレージコストと書き込みコストが増加する。クエリで必要な属性だけを射影するのが基本的な最適化方針になる。 sequenceDiagram participant App as アプリケーション...

RDS Multi-AZを有効にしたのに「パフォーマンスが上がるはず」と期待して、後から「何も変わっていない」と気づく — これは本番環境でよく見かける誤解だ。Multi-AZはパフォーマンス機能ではなく、 高可用性とフェイルオーバー のための機能であり、その設計思想を正しく理解しないと、コストと効果のバランスを見誤る。 TL;DR — RDS Multi-AZの要点 観点 Multi-AZの動作 目的 高可用性・自動フェイルオーバー スタンバイインスタンス 読み取り/書き込みトラフィックを受け付けない（通常時） レプリケーション 同期レプリケーション（プライマリ → スタンバイ） フェイルオーバー所要時間 通常1〜2分（DNSエンドポイント切り替え） 読み取りスケールアウト 対象外（Read Replicaが別途必要） コスト シングルAZ比でインスタンス料金が約2倍 RDS Multi-AZの仕組み — 有効化する前に理解すべきこと Multi-AZを有効にすると、RDSはプライマリインスタンスとは 別のアベイラビリティゾーン にスタンバイインスタンスを自動的にプロビジョニングする。プライマリへの書き込みはすべて同期的にスタンバイへレプリケートされる。つまり、プライマリがコミットを返す前にスタンバイへの書き込みも完了していることが保証される。 この同期レプリケーションが、Multi-AZがパフォーマンス向上に寄与しない理由でもある。書き込みレイテンシはスタンバイへの往復時間分だけ増加する可能性がある。アプリケーションからは単一のDNSエンドポイントしか見えず、スタンバイインスタンスへの直接アクセスは通常時は不可能だ。 graph TD App["アプリケーション"] -->|"単一DNSエンドポイント"| Primary["プライマリインスタンス (AZ-A)"] Primary -->|"同期レプリケーション (コミット前に完了)"| Standby[...

SQSキューから取得したメッセージが複数のコンシューマーに重複処理される——この問題はVisibility Timeoutの設定ミスが原因であることがほとんどだ。処理時間がタイムアウト値を超えた瞬間、SQSはそのメッセージを「未処理」と判断して再度可視化し、別のワーカーが同じメッセージを拾ってしまう。 TL;DR：Visibility Timeoutとは何か 項目 内容 定義 コンシューマーがメッセージを受信してから、他のコンシューマーに見えなくなる時間 デフォルト値 30秒 設定範囲 0秒〜43,200秒（12時間） 二重処理の原因 処理時間がVisibility Timeoutを超えるとメッセージが再可視化される 対策 処理時間に余裕を持たせた値を設定、または処理中に延長APIを呼ぶ 削除タイミング 処理完了後に明示的に DeleteMessage を呼ぶ必要がある Visibility Timeoutの仕組みを理解する SQSはメッセージを受信した時点でそのメッセージを一時的に「不可視」にする。これはキューからメッセージを削除するわけではなく、他のコンシューマーから見えなくするだけだ。コンシューマーが処理を完了して DeleteMessage を呼べばメッセージは消える。しかしVisibility Timeoutが切れる前に削除されなければ、メッセージはキューに戻り、再度取得可能になる。 この設計は意図的なものだ。コンシューマーがクラッシュしたり応答しなくなった場合に、メッセージが失われないようにするためのフェイルセーフとして機能している。問題は、正常に動作しているコンシューマーの処理時間がタイムアウトを超えたときに、同じフェイルセーフが誤発動することだ。 sequenceDiagram participant CA as コンシューマーA participant SQS as SQS キュー participant CB as コンシューマーB CA->>SQS: ReceiveMessage SQS...

新しいサービスを立ち上げるとき、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...

EC2上のアプリケーションにS3アクセスを与えようとしたとき、最初に思いつくのは「IAM Userを作ってアクセスキーを発行すればいい」という方法だ。実際、多くの現場でこのパターンが使われてきたが、これは後になって必ず問題を起こす。IAM UserとIAM Roleの違いを正確に理解していないと、セキュリティインシデントの温床になる設計を量産することになる。 TL;DR — IAM UserとIAM Roleの比較 観点 IAM User IAM Role 認証方式 長期クレデンシャル（アクセスキー／パスワード） 一時的なSTSトークン（自動ローテーション） 主な用途 人間のオペレーター、CLIを使う開発者 AWSサービス、アプリケーション、クロスアカウントアクセス EC2からS3アクセス 非推奨（アクセスキーをインスタンスに配置するリスク） 推奨（インスタンスプロファイル経由で自動取得） クレデンシャル管理 手動ローテーションが必要 STSが自動でローテーション 最小権限の実装 ユーザー単位またはグループ単位 ロール単位、引き受けるエンティティを信頼ポリシーで制御 IAM UserとIAM Roleの仕組みを理解する IAM Userは「人」に対応するアイデンティティだ。ユーザー名とパスワード、またはアクセスキーID／シークレットアクセスキーというロングタームクレデンシャルを持つ。このクレデンシャルは明示的にローテーションしない限り有効であり続ける。 IAM Roleはそれとは根本的に異なる。Roleは「引き受けるもの」であり、それ自体はクレデンシャルを持たない。エンティティ（EC2インスタンス、Lambda関数、別アカウントのユーザーなど）がRoleを引き受けると（AssumeRole）、AWS Security Token Service（STS）が一時的なクレデンシャルを発行する。このトークンは有効期限付きで、自動的に更新される。 IAM Userのアクセスキーは、金庫の鍵を複製して誰かに渡すようなものだ。IAM Roleは、必要なときだけ開く電子錠に近い。鍵そのもの...