RDSで急にパフォーマンスが悪くなったらIOPSを確認!

本番運用しているRDSのパフォーマンスが最近悪くなっている。
スロークエリを確認すると、処理時間が非常に遅いときがある。(Procedure)
とあるProcedure処理が以前は15分くらいで完了していたのだが、遅い時には100分近くかかっている。。。
処理内容は変えていないのに。。。

CPU使用率を比較してみる

グラフの凡例

  • 青線:正常
  • 赤線:処理時間が遅い時

正常時は処理が終わるとCPU使用率は下がっていた。
しかし、処理時間が遅い時は負荷が上がっている時間が短く、CPU使用率も下がりきっていない。
スクリーンショット 2017-05-22 15 (7).png

処理時間が遅いのはCPUがサボっているかららしい(笑)
なぜ、違う動きをしているのか?
実際に処理した件数はどうなっているのか?

IOPSを比較してみる

書き込み(WriteIOPS)

正常時には次の処理が走っているが、それ以外に大きな差はなさそう。
スクリーンショット 2017-05-22 15 (11).png

読み込み(ReadIOPS)

一定時間経過後にIOPSが300で横ばいとなっている。
スクリーンショット 2017-05-22 16.png

Amazon EBS ボリュームとパフォーマンス

色々と調べたところこのページに行き着きました。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSVolumeTypes.html#EBSVolumeTypes_gp2

超ざっくりまとめると…

  • ボリュームサイズによりベースラインパフォーマンスが決まる
  • バーストすることで最大3,000 IOPSまで一時的に性能をあげられる
  • バーストするにはクレジットバランスを消費する
    • クレジットバランスは初期に配られる
    • クレジットバランスはバーストしない間に補充される
  • クレジットバランスを使い切った場合のパフォーマンスはベースラインにとどまる

自分の環境に当てはめる

私の環境はボリュームタイプが「汎用SSD」、ボリュームサイズが「100GiB」なので
ベースラインパフォーマンスは300 IOPSとなっています。

どうやらクレジットバランスを使い切ったため300 IOPSしか性能が出ていなかったようです。。。
ちなみに残クレジットバランスの確認方法はわかりませんでした。(あったら教えてください)

対応方法

対応方法として以下になると思います。
私は後者(処理間隔を空けること)で対応しています。

  • ボリュームサイズを増やす。 ※後から減らせないので要注意!
  • クレジットバランスが補充されるまで待つ

まとめ

INDEXやら色々調べてみてもわからず、この結論に行くまでに時間がかかりました。
普段、意識していない部分だと思うので何かのヒントになれば幸いです。

続きを読む

ECSのAMIで使われる/dev/xvdczについて【cloudpack大阪ブログ】

cloudpack大阪の佐々木です。
ECSでコンテナ用のボリュームを作ったらどこに保存されるか?という話です。

ECSで使うamazon-ecs-optimizedのAMIはデフォルトでは下記のディスク構成になっています。(2015.09.d 以降)

  • /dev/xvda 8G
  • /dev/xvdcz 22G

http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/launch_container_instance.html

Amazon ECS に最適化された、2015.09.d 以降の AMI を使用している場合、インスタンスには 2 つのボリュームが設定されます。[Root] ボリュームはオペレーティングシステム用で、2 番目の Amazon EBS ボリューム (/dev/xvdcz にアタッチ) は Docker 用です。

永続化データを取り扱う場合、ボリュームを追加すると思います。/dev/xvdcz はDocker用ボリュームってことなので、当然そちらに作られるのかと思ったのですが、違うようです。

https://github.com/aws/amazon-ecs-agent/issues/312

/dev/xvdcz is dedicated to layer storage; since volumes are not layers, they’re not stored there.

実際にやってみます。
タスク定義はこんな感じです。

"volumes": [
  {
    "name": "volume-0",
    "host": {
        "sourcePath": "/ecs/mysql"
    }
  }
]

dfではRootボリュームの/dev/xvda1 だけが見えています。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       7.8G  1.7G  6.1G   22% /
devtmpfs         1.9G   96K  1.9G    1% /dev
tmpfs            1.9G     0  1.9G    0% /dev/shm

コンテナにログインし、マウントしているボリュームに2Gのファイルを作成します。

$ docker exec -it 706e24a04caa /bin/bash
root@706e24a04caa:/# dd if=/dev/zero of=/var/lib/mysql/test.out bs=1024 count=2000000
root@706e24a04caa:/# ls -lh /var/lib/mysql/test.out
-rw-r--r-- 1 root root 2.0G Apr 25 04:47 /var/lib/mysql/test.out

ログアウトして、dfを実行してみます。

[ec2-user@ip-172-31-49-18 ~]$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       7.8G  3.6G  4.2G   47% /
devtmpfs         1.9G   96K  1.9G    1% /dev
tmpfs            1.9G     0  1.9G    0% /dev/shm

/dev/xvda1 が増えています。

ではDocker用のボリューム /dev/xvdcz はどんな感じで使われているのでしょうか?
ここに詳しく書いてました。
http://enakai00.hatenablog.com/entry/20140420/1397981156

ホストOSからはこんな感じで見えています。

# lsblk
NAME                                                                                         MAJ:MIN   RM  SIZE RO TYPE MOUNTPOINT
xvda                                                                                         202:0      0    8G  0 disk
└─xvda1                                                                                      202:1      0    8G  0 part /
xvdcz                                                                                        202:26368  0   50G  0 disk
└─xvdcz1                                                                                     202:26369  0   50G  0 part
  ├─docker-docker--pool_tmeta                                                                253:0      0   52M  0 lvm
  │ └─docker-docker--pool                                                                    253:2      0 49.5G  0 lvm
  │   ├─docker-202:1-263192-5c6d48e2f8751428fe02afdadbd0cea776f6019d7ea6b84b3313a66d0c1f8ed7 253:3      0   10G  0 dm
  │   ├─docker-202:1-263192-eca78b256bf5721af414556f0ab42f4436e5ddd2dfb060da1f0ccf843cdbe11a 253:4      0   10G  0 dm
  │   ├─docker-202:1-263192-035491c621338eac035f0a3ee3894dc7c02c0f2989a33bce5e4628226edb1f10 253:5      0   10G  0 dm
  │   ├─docker-202:1-263192-d27d60081d632b3cc0e5b7c7213f40b4eec77d445d0c445abdf69efc83535d54 253:6      0   10G  0 dm
  │   └─docker-202:1-263192-60b1cb416a8ced69c0f6f5c71b842298427dfa406dd7ed6f5f44a56dc3d5f78f 253:7      0   10G  0 dm
  └─docker-docker--pool_tdata                                                                253:1      0 49.5G  0 lvm
    └─docker-docker--pool                                                                    253:2      0 49.5G  0 lvm
      ├─docker-202:1-263192-5c6d48e2f8751428fe02afdadbd0cea776f6019d7ea6b84b3313a66d0c1f8ed7 253:3      0   10G  0 dm
      ├─docker-202:1-263192-eca78b256bf5721af414556f0ab42f4436e5ddd2dfb060da1f0ccf843cdbe11a 253:4      0   10G  0 dm
      ├─docker-202:1-263192-035491c621338eac035f0a3ee3894dc7c02c0f2989a33bce5e4628226edb1f10 253:5      0   10G  0 dm
      ├─docker-202:1-263192-d27d60081d632b3cc0e5b7c7213f40b4eec77d445d0c445abdf69efc83535d54 253:6      0   10G  0 dm
      └─docker-202:1-263192-60b1cb416a8ced69c0f6f5c71b842298427dfa406dd7ed6f5f44a56dc3d5f78f 253:7      0   10G  0 dm

まとめ

ECSで永続化データ用のボリュームを使う場合は、Rootボリュームをあらかじめ大きくしておくか、別ボリュームをアタッチしてマウントしとく必要があるようです。

続きを読む

AWS上でMongoDBを動かす

MongoDBに関する基本的な内容をまとめてみたものです。MongoDBに関する、Web上にすでにある良識な解説コンテンツをまとめたまとめサイトの抜粋です。
AWS上でMongoDBを動かす

AWSであれば、MongoDB環境を容易に構築できる

AWS MarketPlaceには、MongoDB環境を構築するために必要なミドルウェアがプリインストールされたOSイメージが多数あります。
※MongoDBの開発元である 10gen (現MongoDB Inc.)もMongoDB入りイメージを無償提供中

基本的に、それらのイメージをもとにAWSのインスタンスを立ち上げればMongoDB環境ができあがります。英文ですが、下記に具体的な構築手順があります。
http://www.mongodb.org/display/DOCS/AWS+Marketplace

AWSの複数ゾーンとレプリカを組み合わせればDRも容易

MongoDBは、マスタ/スレープ方式のレプリケーションに対応しています。

世界中のデータセンターから選択できる、AWSのさまざまなリージョンやアベイラビリティゾーンを複数選択してMongoDBのレプリカ機能を使用すれば、DR (Disaster Recovery)対応も可能です。

AWSは12のリージョンに、合計で33のアベイラビリティゾーンで運用されています (2016年5月現在)
https://aws.amazon.com/jp/about-aws/global-infrastructure/
AWSのリージョンは、最低でも2つのAZ(アベイラビリティゾーン)をもっていて、それぞれのAZはお互いに地理的・電源的・ネットワーク的に分離されつつも、AZ間は高速専用線で接続されています。

一方のゾーンにMongoDBおよびMongoDBのArbiterインスタンスを立ち上げ、もう一方のゾーンにMongoDBインスタンスを立ち上げれば、片方のゾーンで地震等の災害があっても、データが残り、そのままMongoDBは機能し続けます。

シャードとレプリカを組み合わせたMongoDBクラスタ構成

MongoDBでは、基本的に、シャードを増やすことにより水平スケールさせ、レプリカにより可用性を実現します。各シャードをレプリカセットにすることにより、高い可用性を実現しながら、水平スケールさせた大規模なデータベースを構成することができます。

開発段階では、1 つのレプリカセットから始めることもできますし、本稼働中に 3 つのレプリカセットに移行することもできます。下記URLに、AWS上でMongoDB環境を構築するアーキテクチャ例が示されています。
http://docs.aws.amazon.com/ja_jp/quickstart/latest/mongodb/architecture.html
・図1: レプリケーション係数 3 の MongoDB リファレンスデプロイ
・図2: 3つのレプリカセット2方向シャーディングを使用するAWSのMongoDBクラスター

MongoDBをAWS上で動くようにするまでの手順

AWSにて、MongoDBを動くようにするまでの手順は、概略、下記の通り:

・EC2インスタンスおよびEBSボリュームを用意

・Amazon VPC をセットアップ

*Amazon VPC 内のプライベートサブネットとパブリックサブネット、NAT インスタンス、
セキュリティ グループ、IAM ロールなど、MongoDB のデプロイ中に必要な様々な
ネットワークリソースを作成

・Amazon EBS をセットアップして MongoDB を保存。

・MongoDB 設定をカスタマイズするオプションを指定した後、MongoDBを起動。

MongoDB のバージョン番号 (2.6 または 3.0)、レプリカセットの数 (1 または 3)、シャード数
(0、1、2、または 3)、インスタンスあたりのマイクロシャード数を選択することができます。

※より詳細は、下記を参照ください。
[AWS上の MongoDB] http://docs.aws.amazon.com/ja_jp/quickstart/latest/mongodb/deployment.html

続きを読む

AWS でいままで起きた大規模障害を振り返る

目的

 2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ東京リージョン(主に使っているリージョン)で同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。

所感

  • 毎年どこかのリージョンで大規模な障害が起きている

    • asia-northeast1 で起きていないのはたまたま、運がいいだけ
    • AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの
    • ステータスダッシュボードは時に嘘をつく
    • クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある
    • Chaos Monkey の思想は必須
  • 報告書読むの面白い
  • us-east は呪われている

AWS 障害一覧

  • 報告書が出ているものを網羅できているかとおもいます

    • SimpleDB の障害だけ除外しました。
  • 最近起きたものから過去に遡っていきます

2017/3/1 us-east-1:バージニア北部の S3 が逝く [new!]

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • S3 がアクセス不可
  • 影響した利用者
    • Imgur、IFTTT、Zapier、Slack、Trello など
  • 障害内容
    • まだ
  • 復旧内容
    • まだ
  • 今後の対応
    • まだ
  • 復旧までの時間
    • 3時間 くらい

2016/6/4 ap-southeast-2:豪雨でシドニーの EC2 が逝く

報告書サマリ

  • 障害リージョン

    • ap-southeast-2:アジアパシフィック (シドニー)
  • 障害サービス
    • EC2、Redshift、RDS 等
  • 影響した利用者
  • 障害内容
    • 豪雨により停電
    • UPS への切替時に異常な電圧低下が起きる
    • EC2 落ちまくる
  • 復旧内容
    • 手動で UPS への電源切替を実施
    • 大部分の EC2 は インスタンス管理ソフトにより自動復旧してきた
    • 一部の EC2 インスタンスはインスタンス管理ソフトのバグにより自動復旧されなかったため、手動で回復する
  • 今後の対応
    • 電源周りの見直し
    • 定期的なリカバリテストの実施
  • 復旧までの時間
    • 1.5 時間

2015/9/20 us-east:新機能追加で DynamoDB が逝く

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • DynamoDB がアクセス不可
  • 影響した利用者
    • Netflix、 Reddit 等
  • 障害内容
    • DynamoDB に グローバルセカンダリインデックス(GSI) の機能追加がされる
    • グローバルセカンダリインデックス の利用者増加により、DynamoDB 内部メタデータが急増
    • 内部メタデータを格納しているストレージサーバの容量割当が小さく、メタデータのパーティショニングが発生
    • メタデータの読込性能が劣化し、DynamoDB のエラー率増加
    • 内部的に DynamoDB を使用している EC2 Auto Scaling、SQS、CloudWatch も連鎖的にエラー率増加
  • 復旧内容
    • メタデータサービスの容量追加
  • 今後の対応
    • メタデータサービスの容量割当変更
    • 顧客のサービス利用規模の監視
  • 復旧までの時間
    • 5 時間

2012/12/24 us-east:オペミスにより ELB が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • ELB
  • 影響した利用者
    • Netflix など
  • 障害内容
    • オペレーションミスにより、ELB 管理アプリケーションから ELB の状態管理データが一部論理削除
    • EBL の新規作成はできるが、既存 ELB の状態変更ができない事態へ
  • 復旧内容
    • ELB 状態管理データの手動復旧
  • 今後の対応
    • 運用データへのアクセスポリシー見直し
    • データ復旧プロセスの変更
  • 復旧までの時間
    • 12 時間

2012/10/22 us-east-1:設定ミスにより EBS が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • EBS
  • 影響した利用者
  • 障害内容
    • EBS ストレージ管理サーバの交換作業の一貫で、内部 DNS 設定変更を行ったが設定値にミスがあった
    • ミスった DNS 設定値がなぜか EBS 管理サーバの一部だけに反映される
    • 反映された EBS 管理サーバに、データ収集サーバに接続できないとメモリリークが起きるという潜在バグが発生
    • EBS 管理サーバがメモリ不足によりフェイルオーバーしまくり、フェイルオーバー先が枯渇
    • EBS アクセス不可になる
    • RDS も EBS にアクセスでず、シングル構成のものは死亡、一部 Multi-AZ もバグでフェイルオーバーしなかった
    • ELB も EBS に置いてる構成情報にアクセスできないので自動フェイルオーバーするも、EIP が枯渇して死亡
  • 復旧内容
    • EBS ストレージ管理サーバのメモリ手動解放により、EBS 復旧
    • ELB 手動回復
  • 今後の対応
    • EBS 管理サーバのメモリ監視見直し
    • EBS 管理サーバのフェイルオーバー方法見直し
    • DNS 設定が一部にしか反映できないものを修正
    • RDS フェイルオーバーの不具合修正
    • ELB に追加の EIP を確保
  • 復旧までの時間
    • 14 時間

2012/6/29 us-east-1:嵐により、全体的に逝く

報告書サマリ

  • 障害リージョン

    • us-east-1:米国東部(バージニア北部)
  • 障害サービス
    • EC2、EBS、RDS 等
  • 影響した利用者
    • Netflix、Instagram、Pinterest、Heroku、Flipboard 等
  • 障害内容
    • 落雷のため停電が複数回発生
    • 二度目の発電機への切り替えに失敗、UPS 運用となる
    • 発電機復旧前に UPS 電力枯渇して電源喪失
    • EC2、EBS、RDS など AZ サービスが死亡
  • 復旧内容
    • 発電機復旧
    • EC2 インスタンス管理ソフト はブートプロセスにボトルネックがあり復旧が遅れる
    • EBS は整合性チェックに時間がかかり復旧が遅れる
    • ELB はフェイルオーバー処理を開始するも、不具合にスケールアップし始める
    • 別リージョンでの ELB 処理が溜まりまくって
  • 復旧までの時間
    • 4時間程度

2011/4/21 us-east:設定ミスで EBS、EC2、RDS が逝く

報告書サマリ

  • 障害リージョン

    • us-east:米国東部
  • 障害サービス
    • EBS、EC2、RDS
  • 影響した利用者
    • Heroku 等
  • 障害内容
    • NW 増強のための設定変更実施時に、ルーティング設定のミスが発生
    • ルータがトラフィックを捌ききれず、EBS ノードが NW 分離状態となる
    • 一部ノードがオフラインとなった EBS がミラーリングのために一斉に容量確保を開始、リソース枯渇に陥る
    • 全ノードがオフラインとなった EBS はデータ一貫性が確保できず
    • EC2 インスタンスも起動できなくなる
    • RDS も可用性が低下
  • 復旧内容
    • 障害の起きた EBS ノードを手動切り離し、容量確保
    • データ復旧にとりかかるも、AZ 内データの 0.07% が復旧できなかった
  • 今後の対応
    • ストレージの増強
    • EBS クラスタ制御の改善
    • ヘルスツールの改善
  • 復旧までの時間
    • 4 日

2011/4/14 eu-west:電源喪失で EBS、EC2、RDS が逝く

報告書サマリ

  • 障害リージョン

    • eu-west:欧州
  • 障害サービス
    • EBS、EC2、RDS
  • 影響した利用者
  • 障害内容
    • 変圧器の故障により、電力喪失
    • PLC が不具合により発電機に接続できなかった
    • UPS に切り替わるも電力が不足
    • EC2 でエラー率上昇
    • 一部ノードがオフラインとなった EBS がミラーリングのために一斉に容量確保を開始、リソース枯渇に陥る
    • 全ノードがオフラインとなった EBS はデータ一貫性が確保できず
    • EC2 インスタンスも起動できなくなる
    • RDS も可用性が低下
      • 一つ上のと同じ事象です
  • 復旧内容
    • 手動で発電機に接続、その後電源復旧
    • 不整合の起きた EBS ボリュームのデータ復旧
  • 今後の対応
    • 電源復旧時の EBS ボリュームを自動復旧するよう機能追加
    • EBS スナップショットのバグもついでに見つかり、修正する
  • 復旧までの時間
    • 1 日

参考

続きを読む

AWS 各種サービス料金早見表

目的

 自分用のメモです。
 AWS サービスの料金を聞かれても即答できないことがあるので、AWS 各ページからまとめて金額を引っ張ってきました。更新時点の料金・円レート・東京リージョンのものを記載しています。よく使うものだけ。

 追記:メモなので、価格改定や為替レート変動には対応しません。

EBS

 1GB あたりの容量月額課金。Provisiond IOPS は IOPS 確保に対して課金もある。マグネティックは旧世代の扱いで I/O にも課金がある。

ストレージタイプ 容量1GBあたり$ 円換算 備考 ボリュームサイズ 最大IOPS/ボリューム 最大スループット/ボリューム
General Purpose SSD (gp2) 0.12 13.54 1 GiB~16 TiB 10,000 160 MiB/秒
Provisioned IOPS SSD (io1) 0.142 16.02 $0.074(¥8.35) * プロビジョニングしたIOPS 4 GiB~16 TiB 20,000 320 MiB/秒
Throughput Optimized HDD (st1) 0.054 6.09 500 GiB~16 TiB 500 500 MiB/秒
Cold HDD (sc1) 0.03 3.38 500 GiB~16 TiB 250 250 MiB/秒
S3 Snapshot 0.05 5.64
Magnetic 0.08 9.02 $0.08(¥9.03) / 1万IOPS 1 GiB~1 TiB 40~200 40 ~ 90 MiB/秒

EC2

EC2 インスタンスの料金 – アマゾン ウェブ サービス (AWS)

Linux インスタンス

インスタンスタイプ vCPU ECU メモリ(GiB) インスタンスストレージ(GB) Linux/UNIX 料金
t2.nano 1 可変 0.5 EBS のみ $0.008 /1 時間
t2.micro 1 可変 1 EBS のみ $0.016 /1 時間
t2.small 1 可変 2 EBS のみ $0.032 /1 時間
t2.medium 2 可変 4 EBS のみ $0.064 /1 時間
t2.large 2 可変 8 EBS のみ $0.128 /1 時間
t2.xlarge 4 可変 16 EBS のみ $0.256 /1 時間
t2.2xlarge 8 可変 32 EBS のみ $0.512 /1 時間
m4.large 2 6.5 8 EBS のみ $0.139 /1 時間
m4.xlarge 4 13 16 EBS のみ $0.278 /1 時間
m4.2xlarge 8 26 32 EBS のみ $0.556 /1 時間
m4.4xlarge 16 53.5 64 EBS のみ $1.113 /1 時間
m4.10xlarge 40 124.5 160 EBS のみ $2.782 /1 時間
m4.16xlarge 64 188 256 EBS のみ $4.45 /1 時間
m3.medium 1 3 3.75 1 x 4 SSD $0.096 /1 時間
m3.large 2 6.5 7.5 1 x 32 SSD $0.193 /1 時間
m3.xlarge 4 13 15 2 x 40 SSD $0.385 /1 時間
m3.2xlarge 8 26 30 2 x 80 SSD $0.77 /1 時間
c4.large 2 8 3.75 EBS のみ $0.126 /1 時間
c4.xlarge 4 16 7.5 EBS のみ $0.252 /1 時間
c4.2xlarge 8 31 15 EBS のみ $0.504 /1 時間
c4.4xlarge 16 62 30 EBS のみ $1.008 /1 時間
c4.8xlarge 36 132 60 EBS のみ $2.016 /1 時間
c3.large 2 7 3.75 2 x 16 SSD $0.128 /1 時間
c3.xlarge 4 14 7.5 2 x 40 SSD $0.255 /1 時間
c3.2xlarge 8 28 15 2 x 80 SSD $0.511 /1 時間
c3.4xlarge 16 55 30 2 x 160 SSD $1.021 /1 時間
c3.8xlarge 32 108 60 2 x 320 SSD $2.043 /1 時間
g2.2xlarge 8 26 15 60 SSD $0.898 /1 時間
g2.8xlarge 32 104 60 2 x 120 SSD $3.592 /1 時間
x1.16xlarge 64 174.5 976 1 x 1920 SSD $9.671 /1 時間
x1.32xlarge 128 349 1952 2 x 1920 SSD $19.341 /1 時間
r3.large 2 6.5 15 1 x 32 SSD $0.2 /1 時間
r3.xlarge 4 13 30.5 1 x 80 SSD $0.399 /1 時間
r3.2xlarge 8 26 61 1 x 160 SSD $0.798 /1 時間
r3.4xlarge 16 52 122 1 x 320 SSD $1.596 /1 時間
r3.8xlarge 32 104 244 2 x 320 SSD $3.192 /1 時間
r4.large 2 7 15.25 EBS のみ $0.16 /1 時間
r4.xlarge 4 13.5 30.5 EBS のみ $0.32 /1 時間
r4.2xlarge 8 27 61 EBS のみ $0.64 /1 時間
r4.4xlarge 16 53 122 EBS のみ $1.28 /1 時間
r4.8xlarge 32 99 244 EBS のみ $2.56 /1 時間
r4.16xlarge 64 195 488 EBS のみ $5.12 /1 時間
i3.large 2 7 15.25 1 x 475 NVMe SSD $0.183 /1 時間
i3.xlarge 4 13 30.5 1 x 950 NVMe SSD $0.366 /1 時間
i3.2xlarge 8 27 61 1 x 1900 NVMe SSD $0.732 /1 時間
i3.4xlarge 16 53 122 2 x 1900 NVMe SSD $1.464 /1 時間
i3.8xlarge 32 99 244 4 x 1900 NVMe SSD $2.928 /1 時間
i3.16xlarge 64 200 488 8 x 1900 NVMe SSD $5.856 /1 時間
d2.xlarge 4 14 30.5 3 x 2000 HDD $0.844 /1 時間
d2.2xlarge 8 28 61 6 x 2000 HDD $1.688 /1 時間
d2.4xlarge 16 56 122 12 x 2000 HDD $3.376 /1 時間
d2.8xlarge 36 116 244 24 x 2000 HDD $6.752 /1 時間

Windows インスタンス

インスタンスタイプ vCPU ECU メモリ(GiB) インスタンスストレージ(GB) Windows 料金
t2.nano 1 可変 0.5 EBS のみ $0.0103 /1 時間
t2.micro 1 可変 1 EBS のみ $0.021 /1 時間
t2.small 1 可変 2 EBS のみ $0.041 /1 時間
t2.medium 2 可変 4 EBS のみ $0.082 /1 時間
t2.large 2 可変 8 EBS のみ $0.156 /1 時間
t2.xlarge 4 可変 16 EBS のみ $0.297 /1 時間
t2.2xlarge 8 可変 32 EBS のみ $0.574 /1 時間
m4.large 2 6.5 8 EBS のみ $0.231 /1 時間
m4.xlarge 4 13 16 EBS のみ $0.462 /1 時間
m4.2xlarge 8 26 32 EBS のみ $0.924 /1 時間
m4.4xlarge 16 53.5 64 EBS のみ $1.849 /1 時間
m4.10xlarge 40 124.5 160 EBS のみ $4.622 /1 時間
m4.16xlarge 64 188 256 EBS のみ $7.394 /1 時間
m3.medium 1 3 3.75 1 x 4 SSD $0.146 /1 時間
m3.large 2 6.5 7.5 1 x 32 SSD $0.292 /1 時間
m3.xlarge 4 13 15 2 x 40 SSD $0.583 /1 時間
m3.2xlarge 8 26 30 2 x 80 SSD $1.166 /1 時間
c4.large 2 8 3.75 EBS のみ $0.218 /1 時間
c4.xlarge 4 16 7.5 EBS のみ $0.436 /1 時間
c4.2xlarge 8 31 15 EBS のみ $0.872 /1 時間
c4.4xlarge 16 62 30 EBS のみ $1.744 /1 時間
c4.8xlarge 36 132 60 EBS のみ $3.672 /1 時間
c3.large 2 7 3.75 2 x 16 SSD $0.231 /1 時間
c3.xlarge 4 14 7.5 2 x 40 SSD $0.462 /1 時間
c3.2xlarge 8 28 15 2 x 80 SSD $0.925 /1 時間
c3.4xlarge 16 55 30 2 x 160 SSD $1.849 /1 時間
c3.8xlarge 32 108 60 2 x 320 SSD $3.699 /1 時間
g2.2xlarge 8 26 15 60 SSD $1.01 /1 時間
g2.8xlarge 32 104 60 2 x 120 SSD $3.87 /1 時間
x1.16xlarge 64 174.5 976 1 x 1920 SSD $12.615 /1 時間
x1.32xlarge 128 349 1952 2 x 1920 SSD $25.229 /1 時間
r3.large 2 6.5 15 1 x 32 SSD $0.3 /1 時間
r3.xlarge 4 13 30.5 1 x 80 SSD $0.599 /1 時間
r3.2xlarge 8 26 61 1 x 160 SSD $1.177 /1 時間
r3.4xlarge 16 52 122 1 x 320 SSD $2.276 /1 時間
r3.8xlarge 32 104 244 2 x 320 SSD $4.25 /1 時間
r4.large 2 7 15.25 EBS のみ $0.252 /1 時間
r4.xlarge 4 13.5 30.5 EBS のみ $0.504 /1 時間
r4.2xlarge 8 27 61 EBS のみ $1.008 /1 時間
r4.4xlarge 16 53 122 EBS のみ $2.016 /1 時間
r4.8xlarge 32 99 244 EBS のみ $4.032 /1 時間
r4.16xlarge 64 195 488 EBS のみ $8.064 /1 時間
i3.large 2 7 15.25 1 x 475 NVMe SSD $0.275 /1 時間
i3.xlarge 4 13 30.5 1 x 950 NVMe SSD $0.55 /1 時間
i3.2xlarge 8 27 61 1 x 1900 NVMe SSD $1.1 /1 時間
i3.4xlarge 16 53 122 2 x 1900 NVMe SSD $2.2 /1 時間
i3.8xlarge 32 99 244 4 x 1900 NVMe SSD $4.4 /1 時間
i3.16xlarge 64 200 488 8 x 1900 NVMe SSD $8.8 /1 時間
d2.xlarge 4 14 30.5 3 x 2000 HDD $0.975 /1 時間
d2.2xlarge 8 28 61 6 x 2000 HDD $1.909 /1 時間
d2.4xlarge 16 56 122 12 x 2000 HDD $3.678 /1 時間
d2.8xlarge 36 116 244 24 x 2000 HDD $7.43 /1 時間

EBS 最適化インスタンス 使用量

インスタンスタイプ EBS 最適化使用料
m1.large $0.025 /1 時間
m1.xlarge $0.05 /1 時間
m4.large $0.00 /1 時間
m4.xlarge $0.00 /1 時間
m4.2xlarge $0.00 /1 時間
m4.4xlarge $0.00 /1 時間
m4.10xlarge $0.00 /1 時間
m3.xlarge $0.025 /1 時間
m3.2xlarge $0.05 /1 時間
c4.large $0.00 /1 時間
c4.xlarge $0.00 /1 時間
c4.2xlarge $0.00 /1 時間
c4.4xlarge $0.00 /1 時間
c4.8xlarge $0.00 /1 時間
c3.xlarge $0.02 /1 時間
c3.2xlarge $0.05 /1 時間
c3.4xlarge $0.10 /1 時間
c1.xlarge $0.05 /1 時間
r3.xlarge $0.02 /1 時間
r3.2xlarge $0.05 /1 時間
r3.4xlarge $0.10 /1 時間
m2.2xlarge $0.025 /1 時間
m2.4xlarge $0.05 /1 時間
i2.xlarge $0.02 /1 時間
i2.2xlarge $0.05 /1 時間
i2.4xlarge $0.10 /1 時間
d2.xlarge $0.00 /1 時間
d2.2xlarge $0.00 /1 時間
d2.4xlarge $0.00 /1 時間
d2.8xlarge $0.00 /1 時間

EIP

未割当への課金は IP 枯渇対策ってことでしょうね。

料金 円換算 課金単位
$0.00 ¥0.00 割当中EIP
$0.01 ¥0.56 追加割当EIP/1時間
$0.01 ¥0.56 未割当EIP/1時間
$0.00 ¥0.00 リマップ
$0.10 ¥11.28 リマップ(1か月間で100リマップ超過分)

ELB

AWS | Elastic Load Balancing | Classic Load Balancer の料金

料金 円換算 課金単位
$0.027 ¥3.05 1時間あたり
$0.01 ¥0.90 処理1GBあたり

RDS

料金 – Amazon RDS | AWS
ライセンス費込みだけ記載。

Aurora

インスタンスタイプ 料金/1時間 円換算 vCPU メモリ (GiB) PIOPS 用に最適化 ネットワークパフォーマンス
db.t2.medium $0.13 ¥14.10 2 4
db.r3.large $0.35 ¥39.48 2 15
db.r3.xlarge $0.70 ¥78.96 4 30.5 搭載
db.r3.2xlarge $1.40 ¥157.93 8 61 搭載
db.r3.4xlarge $2.80 ¥315.86 16 122 搭載
db.r3.8xlarge $5.60 ¥631.72 32 244 10 ギガビット

Oracle

インスタンスタイプ 料金/1時間 円換算 vCPU メモリ (GiB) PIOPS 用に最適化 ネットワークパフォーマンス
db.t2.micro $0.04 ¥4.63 1 1
db.t2.small $0.08 ¥9.25 1 2
db.t2.medium $0.16 ¥18.50 2 4
db.t2.large $0.38 ¥43.09 2 8
db.m4.large $0.48 ¥54.49 2 8 搭載
db.m4.xlarge $0.97 ¥109.31 4 16 搭載
db.m4.2xlarge $1.94 ¥218.51 8 32 搭載
db.m4.4xlarge $3.87 ¥437.01 16 64 搭載
db.m3.medium $0.25 ¥27.64 1 3.75
db.m3.large $0.49 ¥55.28 2 7.5
db.m3.xlarge $0.98 ¥110.55 4 15 搭載
db.m3.2xlarge $1.96 ¥221.10 8 30 搭載
db.r3.large $0.53 ¥59.22 2 15
db.r3.xlarge $1.05 ¥118.45 4 30.5 搭載
db.r3.2xlarge $2.10 ¥236.89 8 61 搭載
db.r3.4xlarge $4.20 ¥473.79 16 122 搭載

SQL Server Express

インスタンスタイプ 料金/1時間 円換算 vCPU メモリ (GiB) PIOPS 用に最適化 ネットワークパフォーマンス
db.t2.micro $0.03 ¥3.50 1 1
db.t2.small $0.06 ¥6.99 1 2
db.t2.medium $0.12 ¥13.99 2 4

SQL Server Enterprise

インスタンスタイプ 時間あたり$ 円換算 vCPU メモリ (GiB) PIOPS 用に最適化 ネットワークパフォーマンス
db.r3.2xlarge $5.81 ¥655.41 8 61 搭載
db.r3.4xlarge $11.40 ¥1,286.45 16 122 搭載
db.r3.8xlarge $19.27 ¥2,173.90 32 244 10 ギガビット

続きを読む

Amazon LinuxにアタッチされているEBSのボリュームサイズを拡張する。

はじめに

つい先日、Amazon EBSのアップデートで 「エラスティックボリューム」の発表 がありました。
これはEC2にアタッチされたEBSに対し、「ボリュームサイズの拡張」「パフォーマンスの調整」「ボリュームタイプの変更」がオンラインで行うことができます。
ということで今回、「ボリュームサイズの拡張」を行ってみたいと思います。

事前確認

今回作業するOSは Amazon Linux 2016.09 です。
まずは状況確認しておきます。

デバイスの確認
$ lsblk 
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdb    202:16   0  10G  0 disk /data

現在、 xvdb という名前でボリュームサイズが10GBのデバイスがEC2インスタンスにアタッチされています。

ボリュームの確認
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         236M   60K  236M    1% /dev
tmpfs            246M     0  246M    0% /dev/shm
/dev/xvda1       7.8G  984M  6.7G   13% /
/dev/xvdb        9.8G   23M  9.2G    1% /data

また、 ファイルシステムとしても10GBのボリュームが /data 領域にマウントされているのを確認できます。

今回はこの xvdb のボリュームサイズを拡張します。

EBSサイズの拡張

[EC2] > [ボリューム] から対象となるボリュームをチェックし、[アクション]から[Modify Volume]をクリックします。
expand-ebs01.png

今回は 20GB へ拡張するので「Size」の1020に変更し[Modify]をクリックします。
expand-ebs02.png

「ボリュームの変更をしても本当にいいですか?」と聞かれるので、[Yes]をクリックします。
expand-ebs03.png

すると「in-use optimizing」というステータスになります。変更したサイズへ拡張中です。
expand-ebs04.png

しばらくして「in-use completed」になったらEBS拡張処理の完了です。
expand-ebs05.png

ファイルシステムサイズの拡張

それでは先ほど拡張したボリュームサイズがちゃんと20GBに増えているか確認してみます。

デバイスの確認
$ lsblk 
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk 
└─xvda1 202:1    0   8G  0 part /
xvdb    202:16   0  20G  0 disk /data

無事、20GBのボリュームとして認識されているのが確認できました。
ですが、今のままだとEBSデバイスのサイズが増えただけです。

ボリュームの確認
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         236M   60K  236M    1% /dev
tmpfs            246M     0  246M    0% /dev/shm
/dev/xvda1       7.8G  985M  6.7G   13% /
/dev/xvdb        9.8G   23M  9.2G    1% /data

なので、まだこのままではOSから利用することはできません。
ということでOSから利用できるようにresize2fsでファイルシステムをリサイズします。

ファイルシステムの拡張
$ sudo resize2fs /dev/xvdb 
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/xvdb is mounted on /data; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/xvdb is now 5242880 (4k) blocks long.

これでファイルシステムのリサイズ完了です。

ボリュームの確認
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         236M   60K  236M    1% /dev
tmpfs            246M     0  246M    0% /dev/shm
/dev/xvda1       7.8G  985M  6.7G   13% /
/dev/xvdb         20G   28M   19G    1% /data

ということで無事にOSから利用できるようになりました。

おわりに

これで「とりあえず多めに確保」をする必要も無くなり、「今必要なサイズ」を割り当てれば良くなりました。
また、拡張作業もオンタイムで行えるので、費用面だけでなく運用面のコスト削減にもなります。
これで「いろんな人の負担」がかなり軽くなりますね。

続きを読む

オンラインでボリュームや性能追加できるAmazon EBSのElastic Volume

利用はAWSマネジメントコンソールやAPIコール、AWS CLIから行なえる。AWS CloudFormationのスタック更新機能も利用でき、対象のボリュームに必要な変更 … 続きを読む

Elastic Volumes (Amazon EBS)

ついにEC2インスタンスを起動したままEBSのボリュームタイプと容量・IOPSの変更ができるようになりました!

Elastic Volumes(エラスティックボリューム)という機能だそうです。
新しいボリュームタイプではないのですね。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/considerations.html
を見ると
– Magneticは対象外
– サイズ縮小は当然NG
– 変更後は6時間変更不可
– 2016/11/1以前にアタッチされたボリュームはインスタンスの停止・起動、またはボリュームのデタッチ・アタッチが必要
らしい。他にも制約や前提ありますね。読み込まないと。

紹介記事

続きを読む

EFSとEBS

AWSのストレージサービス

AWSには以下のようなストレージサービスが提供されています。

  • インスタンスストレージ
  • EBS
  • EFS
  • S3
  • Glacier
  • Storage Gateway
  • RDS
  • Redshift
  • ElastiCache
  • DynamoDB
  • (SimpleDB)

ここではEFSとEBSの比較について特徴と利用方法を取り上げます。

EFSとEBSの比較

EFSはNFSでアクセス可能な共有ストレージのファイルストレージサービスで、EBSはブロックレベルのストレージサービスで、共にEC2にマウント可能なストレージです。EFSとEBSの利用比較の図については以下のようになります。
efs_ebs.png

公式ページの比較表を引用させて頂くと以下のようになります。

Amazon EFS Amazon EBS PIOPS
パフォーマンス オペレーションあたりのレイテンシー 低、一定 最低、一定
スループットスケール 1 秒間あたり数 GB 1 秒間あたり 1 GB
特徴 データ(可用性/耐久性) 複数 AZ に冗長的に保存 単一 AZ に冗長的に保存
アクセス 複数 AZ の 1~数千の EC2 インスタンスから同時 単一 AZ の単一 EC2 インスタンスから
ユースケース ビッグデータと分析、メディア処理ワークフロー、コンテンツ管理、ウェブ配信、ホームディレクトリ ブートボリューム、トランザクションおよび NoSQL データベース、データウェアハウスと ETL

制限

マウントコマンド まとめ

EFS

$ sudo yum install nfs-utils
$ sudo mkdir -p /mnt/efs/0
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs/0
$ df -h
$ sudo bash -c "echo 'fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs/0 nfs4 defaults 0 0' >> /etc/fstab"

EBS

$ sudo mkfs.xfs /dev/sdf
$ sudo mkdir -p /mnt/ebs/0
$ sudo mount -t xfs /dev/sdf /mnt/ebs/0
$ df -h
$ sudo bash -c "echo '/dev/sdf /mnt/ebs/0 xfs defaults 0 0' >> /etc/fstab"

利用方法

EFS

マネジメントコンソールから[Elastic File System]を選択。
[Create file system]を選択。

Step 1: Configure file system access

VPC: vpc-xxxxxxxxx
Create mount targets:
Availability Zone, Subnet, IP address, Security groupsの各項目について、利用するリージョン中のアベイラビリティゾーンが幾つか表示される。

[Next step]を選択。

Step 2: Configure optional settings

Add tags

Key: Name
Value: SampleEFS

Choose performance mode

  • General Purpose
  • Max I/O

パフォーマンスモードは2種類から選択できる。Max I/Oはインスタンスが10個〜1000個の規模で接続するのに向いている。通常はGeneral Purposeで良い。CloudWatchのPercentIOLimitのIOの様子を見てMax I/Oを考える。

[Next step]を選択。

Step 3: Review and create

内容を確認したら、[Create File System]を選択。

※注意点で、EFS側のセキュリティグループでインバウンドでEFSの通信を許可しておかないとタイムアウトでマウントに失敗するので、ポートを開放しておく。

EFSのMount targetsで各AZに適用されているSecurity Groupを確認しておく。
マネジメントコンソールから[VPC]を選択。
[セキュリティグループ]を選択。
先ほど確認したセキュリティグループを選択し、インバウンドルールを選択して、[編集]を選択。

[別のルールの追加]を選択して、以下を追加して[保存]を選択する。

カスタムTCPルール TCP(6) 2049 0.0.0.0/0

$ ssh -i ~/.ssh/id_rsa.pem ec2-user@XXX.XXX.XXX.XXX

以下を入力しても何も表示されない場合はnfs-utilsがインストールされていないのでインストールする。

$ yum list installed | grep nfs-utils
nfs-utils.x86_64                         1:1.3.0-0.21.amzn1           @amzn-main
$ sudo yum install nfs-utils
$ sudo mkdir -p /mnt/efs/0
$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs/0
$ df -h
ファイルシス                              サイズ  使用  残り 使用% マウント位置
/dev/xvda1                                  7.8G  1.2G  6.6G   15% /
devtmpfs                                    488M   60K  488M    1% /dev
tmpfs                                       498M     0  498M    0% /dev/shm
fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/   8.0E     0  8.0E    0% /mnt/efs/0
$ sudo bash -c "echo 'hoge' > /efs/sample.txt"
  • ユーザに実行権限がないディレクトリのファイルに対してリダイレクトでデータを書き込みとsudo をつけても失敗する。
  • もしくは、sudo tee -a /efs/sample.txt

としておき、別のインスタンスからも同様の手順でマウントすると、

$ cat /efs/sample.txt 
hoge

ファイルが共有できることが確認できる。

Amazon Linux, Red Hat Enterprise Linux, or SuSE Linuxでは、nfs-utilsパッケージ
Ubuntuでは、nfs-commonパッケージ

nfs-utilsパッケージを使用するが、Amazon Linuxではデフォルトでインストールされているので、yumなどでインストールする必要はない。

再起動してもマウントが外れないように/etc/fstabにマウントの情報を追記しておく。

$ sudo bash -c "echo 'fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs/0 nfs4 defaults 0 0' >> /etc/fstab"

注意点

nfs-utilsを入れ直さないと

$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /efs
mount: wrong fs type, bad option, bad superblock on fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

(参考) http://qiita.com/Accent/items/0d99c4652e2101760b50

$ sudo yum install nfs-utils

ファイアウォールを解放しないと

$ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ efs
mount.nfs4: Connection timed out

EBS

マネジメントコンソールの操作

1.マネジメントコンソールから、[EC2]を選択。
2.ELASTIC BLOCK STOREの[ボリューム]を選択。
3.[ボリュームの作成]を選択。

4.
ボリュームタイプ: 汎用SSD(GP2)
サイズ(GiB): 5(最小: 1 GiB、最大: 16384 GiB)
IOPS: 300 / 3000(Baseline of 3 IOPS per GiB with a minimum of 100 IOPS, burstable to 3000 IOPS)
スループット (MB/秒): 該当しません
アベイラビリティーゾーン : us-east-1d
スナップショット ID: (空欄)
暗号化: (チェックしない)

[作成]を選択。

EBSはアベイラビリティーゾーンに属するので、アタッチしたいEC2インスタンスがあるものと同じものにしておかないといけないことに注意。

5.作成したボリュームを選択した状態で[アクション]から[ボリュームのアタッチ]を選択。

6.
ボリューム : us-east-1d にある vol-0bf1030e59290b4f8
インスタンス : i-e25cdcd2 us-east-1d 内の
デバイス : /dev/sdf

  • Linux のデバイス: /dev/sdf から /dev/sdp

[アタッチ]を選択。

7.デバイスの存在を確認。

CUIからの操作

$ ssh -i ~/.ssh/id_rsa.pem ec2-user@XXX.XXX.XXX.XXX
$ ls -al /dev/ | grep sdf
lrwxrwxrwx  1 root root           4  1月  2 06:16 sdf -> xvdf

xfsprogsパッケージが必要。Amazon Linuxではデフォルトでインストールされている。

$ sudo mkfs.xfs /dev/sdf
meta-data=/dev/sdf               isize=256    agcount=4, agsize=327680 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=1310720, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
$ sudo mkdir -p /mnt/ebs/0
$ sudo mount -t xfs /dev/sdf /mnt/ebs/0
$ df -h
ファイルシス                              サイズ  使用  残り 使用% マウント位置
/dev/xvda1                                  7.8G  1.2G  6.6G   15% /
devtmpfs                                    488M   64K  488M    1% /dev
tmpfs                                       498M     0  498M    0% /dev/shm
fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/   8.0E     0  8.0E    0% /mnt/efs/0
/dev/xvdf                                   5.0G   33M  5.0G    1% /mnt/ebs/0

再起動してもマウントが外れないように/etc/fstabにマウントの情報を追記しておく。

$ sudo bash -c "echo '/dev/sdf /mnt/ebs/0 xfs defaults 0 0' >> /etc/fstab"

その他

ルートデバイスボリュームの容量の追加

AMIの作成
AMIや元々のインスタンスの設定によっては、サイズの変更が反映されないので以下のコマンドを入力する。

$ sudo resize2fs /dev/xvda1

追加ボリュームの容量の追加。

$ sudo resize2fs /dev/xvdf

ファイルシステムがXFSの場合は以下のコマンドを入力する。

$ sudo xfs_growfs /mnt/ebs/0

参考

http://docs.aws.amazon.com/efs/latest/ug//mounting-fs.html
http://dev.classmethod.jp/cloud/aws/amazon-elastic-file-system-is-generally-available/
http://dev.classmethod.jp/cloud/efs-ataglance/
http://blog.serverworks.co.jp/tech/2016/06/29/efs-2/

続きを読む

AWS EC2にMongoDBインストールとレプリケーション設定

MongoDBインストールとレプリケーション設定について、簡易的な抜粋メモとして書いています。
詳細に関しては、記事の最後の参考サイトを確認するようにしてください。

◆ 今日やること

  • MongoDBをEC2にインストール
  • レプリケーションの設定と確認
    • 今回せっていするレプリケーションの形式は、以下の図の通り、「Primary with Secondary Members」です。

mongorepl.png
引用元:Replication — MongoDB Manual 3.4

◆ バージョン

  • MongoDB 3.2
  • Linux 4.4.30-32.54.amzn1.x86_64 #1 SMP Thu Nov 10 15:52:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

◆ 実装編

> EC2へのインストール

sudo yum update -y
sudo vim /etc/yum.repos.d/mongodb-org-3.2.repo

[mongodb-org-3.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc
sudo yum install -y mongodb-org
sudo service mongod start

sudo chkconfig mongod on

> 設定周り

  • WoredTigerストレージエンジンの主な設定

    • cacheSizeGB: システムメモリの6、7割
    • blockCompressor:デフォルトはsnappy(中間です)
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
       cacheSizeGB: 1
       journalCompressor: snappy
    collectionConfig:
       blockCompressor: snappy

> EBSボリュームをAttach

  • EBSボリュームにmongoのデータを溜めるようにする。

Amazon EBS ボリュームを使用できるようにする – Amazon Elastic Compute Cloudに従って、EBSボリュームをアタッチする

  • パーミッションを変更するのを忘れないように。
sudo chown -R mongod:mongod /data
  • /etc/mongod.conf
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data

> レプリケーションの設定

MongoDBではマスターのことをプライマリ,スレーブのことをセカンダリと呼びます。
MongoDBのレプリケーションの最小構成は,3つのノードが必要です。

  • ネットワークインターフェイスの設定で、レプリケーションを組むサーバのIPを記述しておくこと

レプリケーション設定前には、お互いに通信できることを確認しないといけません
Troubleshoot Replica Sets — MongoDB Manual 3.4

mongodb が listen するIPアドレスはデフォルトでは 127.0.0.1 に設定されており、ローカルからのみアクセスを許可するようになっています
mongod.conf の bind_ip に設定されたIPアドレスで listen するのでこれを変更することで外部からの接続を許可します
ここに 0.0.0.0 を設定すると全てのIPアドレスからの接続を許可します

/etc/mongod.conf
# network interfaces
net:
  port: 27017
  bindIp: [127.0.0.1,10.1.52.111,10.1.51.227,10.1.51.68]


  • レプリケーション名を決める
  • Oplogのサイジングと設定サイズを決める
/etc/mongod.conf
replication:
   oplogSizeMB: 500
   replSetName: testRepl

第4回 MongoDBのレプリケーションを構築してみよう:MongoDBでゆるふわDB体験|gihyo.jp … 技術評論社

OplogはCapped Collectionなので,作成時以外にサイズ変更することができません。 デフォルトのOplogのサイズは「1GBまたは,ディスクの空き領域の5%」
Staleを避けるために,Oplogのサイジングは非常に重要となります。
Oplogのサイズは,mongodの初回起動時にoplogSizeオプションで変更可能です。
Oplogの適切なサイズを見積もる方法のひとつに,本番を想定した書き込みテストを実施し,作成されたOplogのサイズを取得する方法があります。
1時間程度,本番想定と同程度の書き込みテストを行った後,以下のコマンドでレプリケーションの最新情報を取得します。

> db.getReplicationInfo()

1時間で作成されたOplogのサイズがわかれば,Oplogのサイジングの目安となります。
少なくとも8時間のセカンダリのダウンタイムに耐えられるようにしておくことが推奨されています。

  • レプリケーションの設定

どれかのサーバに入って、以下のコマンドを実行

config = {
  _id : "testRepl",
  members : [
    { _id : 0, host : "10.1.51.227:27017" },
    { _id : 1, host : "10.1.51.68:27017" },
    { _id : 2, host : "10.1.52.111:27017"} ] }

rs.initiate(config)
  • スレーブの読み取り専用動作設定

そのままだと、スレーブが読み取り専用としてアクセスできないので以下の設定を行っておく。

スレーブノードで、以下のコマンドを実行

 db.getMongo().setSlaveOk()
  • レプリケーションステータスの確認
testRepl:PRIMARY> rs.status();
{
    "set" : "connobaRepl",
    "date" : ISODate("2017-01-12T07:03:05.556Z"),
    "myState" : 1,
    "term" : NumberLong(6),
    "heartbeatIntervalMillis" : NumberLong(2000),
    "members" : [
        {
            "_id" : 0,
            "name" : "10.1.51.227:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 100310,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "electionTime" : Timestamp(1484104344, 1),
            "electionDate" : ISODate("2017-01-11T03:12:24Z"),
            "configVersion" : 3,
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "10.1.51.68:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 100245,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:04.017Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:04.020Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        },
        {
            "_id" : 2,
            "name" : "10.1.52.47:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 99751,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:05.025Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:05.022Z"),
            "pingMs" : NumberLong(2),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        }
    ],
    "ok" : 1
}

> mongoログインの時の警告メッセージを消す方法

[ec2-user@ip-10-1-52-47 ~]$ mongo
MongoDB shell version: 3.2.11
connecting to: test
Server has startup warnings:
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
testRepl:SECONDARY>

◆ 参考サイト

続きを読む