投稿

ラベル(クラウドインフラ)が付いた投稿を表示しています

複数EC2インスタンス間でフォルダを共有する:EBSとEFSの使い分け完全ガイド

5台のEC2インスタンスで同じディレクトリをマウントしたい——この要件を受けて、まずEBSのマルチアタッチを試みたエンジニアは少なくない。結論から言うと、EBSは原則として複数インスタンスへの同時共有には向いておらず、EC2間でフォルダを共有するには Amazon EFS(Elastic File System) が正しい選択肢になる。 TL;DR:EBS vs EFS、複数インスタンス共有の判断基準 観点 EBS EFS 複数インスタンスへの同時マウント 原則不可(Multi-Attachは限定的) 可能(同一リージョン内) 対応ストレージプロトコル ブロックストレージ NFSv4.1 / NFSv4.0 ファイルシステム共有 不可(Multi-Attach時もファイルシステム層は非共有) 可能(POSIX準拠) 対応インスタンス数 Multi-Attachは最大16インスタンス(io1/io2のみ) 数千インスタンスまでスケール AZ制約 同一AZのみ リージョン内複数AZに対応 ユースケース 単一インスタンスのOSディスク、DB 共有コンテンツ、ログ集約、CMS EBSとEFSの仕組み:なぜEBSでは共有できないのか EBSはブロックストレージデバイスとして動作する。EC2インスタンスにアタッチされると、インスタンス側でext4やxfsなどのファイルシステムをフォーマットして使う構造になっている。ファイルシステムのメタデータ(inode、ジャーナル)はEBSボリューム上に書き込まれるため、複数のインスタンスが同じボリュームを同時にマウントすると、メタデータが競合してファイルシステムが破損する。 EBSにはio1/io2ボリュームタイプ限定で Multi-Attach という機能があり、最大16インスタンスへの同時アタッチが可能だ。ただし、これはブロックデバイスレベルの共有であり、ファイルシステムの同時書き込みを安全に扱うには クラスタ対応ファイルシステム(例:GFS2) をアプリケーション側で実装する必要がある。通常のext4/xfsでMulti-Attachを...

RDSスナップショットからの復元:既存インスタンスは上書きされるのか、新しいエンドポイントが作成されるのか

本番環境でデータ破損が発生し、RDSスナップショットから急いで復元しようとしたとき、多くのエンジニアが同じ疑問にぶつかる。「既存のインスタンスが上書きされるのか、それとも別のエンドポイントを持つ新しいインスタンスが作られるのか」——この挙動を誤解したまま復元操作を実行すると、アプリケーションの接続先が変わらず、復元したはずのデータに誰もアクセスできないという状況が生まれる。RDSスナップショット復元の動作原理を正確に理解しておくことは、障害対応の成否を左右する。 TL;DR:RDSスナップショット復元の要点 項目 挙動 既存インスタンスの上書き 行われない。常に新しいインスタンスが作成される エンドポイント 新しいインスタンス固有のエンドポイントが割り当てられる 元のインスタンス 復元操作後も変更されずそのまま稼働し続ける パラメータグループ / セキュリティグループ デフォルト設定が適用される。元の設定は引き継がれない アプリケーション切り替え エンドポイントの手動変更またはRoute 53 CNAMEの更新が必要 マルチAZ / リードレプリカ 復元時に再設定が必要。スナップショットには含まれない RDSスナップショット復元の仕組み RDSのスナップショット復元は、既存インスタンスへの変更操作ではなく、スナップショットを元にした 新規インスタンスのプロビジョニング として実装されている。これはAWSの設計上の意図であり、復元操作が元のデータを誤って破壊するリスクを排除するための安全機構でもある。 スナップショット自体はS3上に保存されたストレージボリュームのポイントインタイムコピーであり、インスタンスの設定情報(パラメータグループ、セキュリティグループ、マルチAZ設定など)は含まれない。復元時にAWSは新しいDBインスタンス識別子を要求し、そのIDに基づいた新しいエンドポイントを生成する。 graph TD A["稼働中のRDSインスタンス prod-db"] -->|"スナップショット取得"| B[...

EBS gp2とgp3の選び方:IOPSを独立してスケールできるのはどちらか

EC2インスタンスのストレージを設定しているとき、General Purpose SSDの選択肢として gp2 と gp3 が並んでいる。どちらを選ぶべきか迷った経験は多いはずだ。特に「ストレージ容量を増やさずにIOPSだけ上げたい」という要件が出たとき、gp2とgp3の設計思想の違いが初めて問題になる。 TL;DR:gp2とgp3の比較 項目 gp2 gp3 IOPSのスケール方式 容量に連動(3 IOPS/GB) 容量と独立して設定可能 ベースラインIOPS 100〜16,000 IOPS(容量依存) 3,000 IOPS(固定ベースライン) 最大IOPS 16,000 IOPS 16,000 IOPS 最大スループット 250 MiB/s 1,000 MiB/s バーストクレジット あり(クレジットバケット方式) なし(常時ベースライン保証) コスト傾向 gp3より割高になりやすい 同等性能でgp2より安価になることが多い gp2とgp3の仕組みを理解する gp2はIOPSが容量に紐付いている。具体的には1 GBあたり3 IOPSが割り当てられ、100 GBのボリュームなら300 IOPS、1,000 GBなら3,000 IOPSが得られる。ベースラインは最小100 IOPS、最大16,000 IOPSだ。さらにgp2にはバーストクレジットの仕組みがある。ベースラインIOPSを下回る使用状況のときにクレジットが蓄積され、一時的に3,000 IOPSまでバーストできる(ただし1 TB未満のボリュームに限る)。 gp3はこの連動を切り離した。すべてのgp3ボリュームは容量に関係なく3,000 IOPSと125 ...