7/27 に開催された AWS Black Belt Online Seminar「Amazon Elastic File System」に参加した！メモを残しておく．

資料

AWS Black Belt Online Seminar Amazon Elastic File System from Amazon Web Services Japan

www.slideshare.net

メモ φ(..)

リージョン
- 6/29 に GA になった
  - バージニア
  - オレゴン
  - アイルランド
- 東京はまだ未定
CDP
- 現在の CDP だと NFS が SPOF になるため，自前で冗長化構成を考える必要があった
- "NFS Sharing" の NFS 部分を Amazon EFS に置き換えられる
- シンプルかつスケーラブルに運用できるようになる
課金体系
- Amazon EFS に保存しているデータ量で課金される
- S3 とは違って転送量で課金はされない
- データ量に比例して IOPS も上がっていく仕組みになっているが，データ量が少ない場合もバーストできる
- 1000台以上の EC2 から接続することもできる
AZ
- AZ を意識する必要は無く Amazon EFS 側で AZ にレプリケーションされる
- よってどの AZ に所属している EC2 からも接続できる
マウントターゲット
- サブネット内にマウントターゲットを用意して EC2 からマウントする
- マウントターゲットにセキュリティグループを設定できるため，誤った EC2 から接続できないようにするなどセキュアに運用できる
性能
- GP : General Purpose モード
- Max I/O モード
- 原則 GP モードを推奨する
- CloudWatch のメトリクス次第で Max I/O モードを検討する
- ただし GP → Max I/O に移行する場合は EFS を作り直す必要がある
NFS 仕様
- NFS 4.0 / 4.1 をサポート
- パフォーマンス的に NFS 4.1 を推奨する
整合性
- 一貫性を保証していて「全ての読み込みは最新のデータが反映されている」
- S3 の特徴である結果整合性 (Eeventually Consistency) とは違う
- 用途次第でファイルをロックすることもできる
運用
- df すると 8.0E と表示される
サービス連携
- AWS Data Pipeline と連携してデータのハウスキーピングなどを行うこともできる
制約
- NFS だからネットワークレイテンシは考慮する必要がある
- 制約を理解した上で用途を考える
- またインスタンスタイプによってネットワーク性能の上限が決まっている場合があり Amazon EFS の性能より下回る場合もある
- あくまで VPC 内に限定されるため VPC は跨げない
バースト
- バーストはクレジット性になっている
- T2 インスタンスと同じ
- 容量単価で考えると EBS より約3倍高くなっている
- AZ 間でレプリケーションしているためと考える

感じたこと

東京リージョンに期待！
S3 だと API 経由でファイルアクセスをする必要があるから Amazon EFS は EBS のように扱えて楽そう
df するとエクサバイトになるのはワロタ
- もし df 結果を加工してメトリクスを収集してたりするとグラフの上限がヤバイことになりそう（笑）
AZ を考慮して容量単価が決まっているなら東京だと約2倍？
質疑応答
- 質問が多すぎて時間切れになっていた
- 多岐にわたる質問が出るから Amazon EFS 以外の知識も幅広く持っている必要があって，普通に凄いなと思った
- 質問は管理者にしか見えないようになっているから，他の参加者のことを気にせずに質問することができるのは良かった