パーティションされていないマウントされている EBS をオンラインで拡張する(XFS編)

Amazon EBSのアップデートで 「エラスティックボリューム」の発表 でずっと試してみたいなと思っていたのをテストしてみたので記事にします。

Qiitaを見ると既に一杯記事が上がっています。

1.まずボリュームサイズの変更
EBSボリュームのサイズ変更をやってみる – Qiita
 –>この記事ではボリュームサイズの変更のみ

2.ルートデバイス以外の場合
Amazon LinuxにアタッチされているEBSのボリュームサイズを拡張する。 – Qiita
 –>スクリーンショット付きで分かりやすいです。初心者向け

3.ルートデバイスのEBSでは一手間必要です
オンラインでEC2のルートディスクを拡張する – Qiita
 –>そのまま、resize2fs ではダメなようです
   sudo growpart /dev/xvda 1を追加作業しています

4.結論だけとっととみたい人向け
rootにmountされているEBSを、mountしたまま拡張する手順 – Qiita
 –>いきなり、growpart /dev/xvda 1 してます

5.Ubuntuでも同様にリサイズ可能です
AWS EBSのルートディスク拡張した際のサイズ拡張のやりかた – Qiita
 —>Ubuntu 14.04です

6.再起動すると適用されます
EC2のボリューム(EBS)容量拡張方法検証 (AmazonLinux) – Qiita
 —>実は再起動したときに自動的に拡張されるようです。
   再起動可能で手間を省きたい人向け

7.最後は自動でリサイズされるスクリプトです
AWS EBSのリサイズをシェルスクリプトにまとめてみた – Qiita
 –>費用を最小限に抑えられますね。

他にも記事がありましたが、ボリュームをデタッチしたりしていたので除外しました。

で、今さら感は非常にあるのですが、XFSでやってみた人がいないので書いてみます。
作業した OS は CentOS-7.3 Official Image です。

1. ボリュームを用意

今回は、ルートボリューム以外の場所をNFSデータ領域としてつかってみることにしたので、10GiBほどEBSを作ってみました。

image.png

アタッチが終了したので Diskの状況はこんな感じです

[root@ ~]# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  200G  0 disk
└─xvda1 202:1    0  200G  0 part /
xvdg    202:96   0   10G  0 disk

xvdg として接続されています。

2. XFSでフォーマットする

NFSのデータ領域として使うのでXFSを選択しました。
パーティションを作るとボリューム拡張した時にパーティションも拡張しないといけないので、パーティション無しでXFSをフォーマットします。

[root@ ~]# mkfs.xfs /dev/xvdg
meta-data=/dev/xvdg              isize=512    agcount=4, agsize=655360 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
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

3. マウントします

マウントしてみますが、とりあえずテスト用のディレクトリにマウントしてみます。

[root@ ~]# mkdir /test_mount
[root@ ~]# mount /dev/xvdg  /test_mount/
[root@ test_mount]# df -h
Filesystem      Size  Used Avail Use% Mounted on
  <<<中略>>>
/dev/xvdg        10G   33M   10G   1% /test_mount

大丈夫のようです

4. ボリュームを拡張する

ボリューム拡張の方法は記載しませんが、以下のように20GiBに拡張されました。
image.png

以下のように増えています。

[root@ ~]# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  <<<中略>>>
xvdg    202:96   0   20G  0 disk /test_mount

5. ファイルシステムをリサイズする

この状態では、ファイルシステムは以下のままです。

[root@ test_mount]# df -h
Filesystem      Size  Used Avail Use% Mounted on
  <<<中略>>>
/dev/xvdg        10G   33M   10G   1% /test_mount

xfs_growfs コマンドでXFSファイルシステムを拡張します

[root@ test_mount]# xfs_growfs /dev/xvdg
meta-data=/dev/xvdg              isize=512    agcount=4, agsize=655360 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2621440 to 5242880

6. 拡張されたか確認する

確認してみます。

[root@ test_mount]# df -h
Filesystem      Size  Used Avail Use% Mounted on
  <<<中略>>>
/dev/xvdg        20G   33M   20G   1% /test_mount

増えてますね。

7. まとめ

パーティションを切らずにファイルシステムを作れば簡単にファイルシステムを拡張出来ることが分かりました。ますます、AWSが便利に使えそうです。

#この記事を書く前は、「パーティションを切らずにファイルシステムをフォーマットできる」と言うことを知らず、ボリューム全体を一つのパーティションにする方法ばかり調べていました。ボリュームをそのままファイルシステムでフォーマットすればいいということを知ったので書いてみました。

続きを読む

AWS 認定ソリューションアーキテクト – アソシエイト 合格までに勉強したこと

概要

AWS 認定試験には「これを勉強すればいいよ!」という教科書があるわけではないので、何を勉強したらいいか分からず困っている人も多いと思います。
なので、私の勉強記録を共有します。

勉強前のスペック

AWSの初級者です。
EC2インスタンス起動やEBSのスナップショット取得の経験があるくらいでした。

勉強方法概要

AWS活用本を一冊読んで、
あとはAWS クラウドサービス活用資料集にある BlackBelt のスライド(PDF)を淡々と読みました。

その後、模擬試験を受けて本試験を受験しました。

勉強方法詳細

少し前に買っていた以下の本を読みました。分かりやすいです。

Amazon Web Services 定番業務システム12パターン設計ガイド

BlackBelt

自分が読んだ資料に○を付けました。
また、模擬試験と本試験を受けた経験から、各資料の重要度を評価しました。
※当たり前ですが、読んでいない資料の重要度は評価していません。また、重要度の正確性も保証しません。

コンピューティング

資料 読んだ  重要度 
[Amazon EC2] 
[Amazon EC2] Windows
[Amazon EC2] HPC
[Amazon EC2] リザーブドインスタンス
[Amazon EC2] スポットインスタンス
[Amazon EC2] Instance Store & Elastic Block Store
[Amazon EC2] VMImport/Export
[Elastic Load Balancing]
[Elastic Load Balancing] ロードバランサと Socket 接続を使用したイベント通知サーバの負荷分散
[Elastic Load Balancing] ELBを評価するためのベストプラクティス
[Auto Scaling]
[Amazon EC2 Container Service]
[AWS Elastic Beanstalk]
[AWS Lambda]
[AWS Lambda] update
[Amazon Lightsail]
[AWS Batch]

ストレージ & コンテンツ配信

資料 読んだ  重要度 
[Amazon EBS]
[Amazon S3] 
[Amazon CloudFront]
[Amazon CloudFront] Flash Media Server on AWS
[Amazon CloudFront] CloudFront 上限緩和申請 計算方法&申請手順
[Amazon CloudFront] まだ間に合う! Amazon CloudFront で ATS 対応
[Amazon Glacier]
[Amazon Glacier] 機能編
[AWS Storage Gateway]
[Amazon Elastic File System]

データベース

資料 読んだ  重要度 
[Amazon RDS]
[Amazon RDS] Aurora
[Amazon DynamoDB]
[Amazon ElastiCache]
[Amazon ElastiCache] Redis QA資料
[Amazon Redshift] 
[Amazon Database Migration Service]

ネットワーキング

資料 読んだ  重要度 
[Amazon VPC]
[Amazon VPC] VPN接続設定 参考資料
[AWS Direct Connect] 
[Amazon Route53]

開発者用ツール

資料 読んだ  重要度 
[AWS CodeCommit]
[AWS CodeBuild]
[AWS CodeDeploy]
[AWS CodePipeline]
[AWS SDK]
[AWS SDK] Java & .NET
[AWS SDK] PHP & Ruby & Boto(Python) & Javascript in Node.js
[AWS SDK] AWS Client side SDK Android & iOS & Javascript
[AWS CLI]
[AWS AWS Tools for Windows Powershell]

管理ツール

資料 読んだ  重要度 
[Amazon CloudWatch]
[AWS CloudFormation]
[AWS CloudTrail]
[AWS Config]
[AWS OpsWorks] AWS OpsWorksのご紹介
[AWS OpsWorks]
[AWS OpsWorks] ハンズオン
[AWS Service Catalog]
[Trusted Advisor] AWS サポート & Trusted Advisor
[Amazon EC2 Systems Manager]

セキュリティ & アイデンティ

資料 読んだ  重要度 
[Identity and Access Management (IAM)] 
[AWS CloudHSM] CloudHSM & Key Management Service
[AWS Key Management Service]
[AWS Directory Service]
[Amazon Inspector]
[AWS WAF]
[AWS Certificate Manager]

分析

資料 読んだ  重要度 
[Amazon EMR(Elastic MapReduce)]
[AWS Data Pipeline]
[Amazon Elasticsearch Service] Amazon CloudSearch & Amazon Elasticsearch Service
[Amazon Kinesis]
[Amazon QuickSight]
[Amazon Athena]

AI

資料 読んだ  重要度 
[Amazon AI]]

IoT

資料 読んだ  重要度 
[AWS IoT]

ゲーム開発

資料 読んだ  重要度 
[Amazon Lumberyard]

モバイルサービス

資料 読んだ  重要度 
[Amazon Cognito]
[Amazon Cognito] Amazon Cognito update
[Amazon Cognito] Amazon Cognito / Amazon Mobile Analytics
[AWS Device Farm]
[Amazon Mobile Analytics] Amazon Cognito / Amazon Mobile Analytics
[Amazon SNS] Amazon SNS/SQS
[Amazon SNS] モバイルプッシュ通知
[Amazon Pinpoint]  

アプリケーションサービス

資料 読んだ  重要度 
[Amazon API Gateway] 
[Amazon AppStream]
[Amazon CloudSearch] Amazon CloudSearch & Amazon Elasticsearch Service
[Amazon Elastic Transcoder]
[Amazon SES]
[Amazon SES] Amazon SES-Easy DKIM 設定サポート資料
[Amazon SQS] Amazon SNS/SQS
[Amazon Simple Workflow Service (SWF)]

エンタープライズアプリケーション

資料 読んだ  重要度 
[Amazon WorkSpaces]
[Amazon WorkDocs]
[Amazon WorkMail]
[Amazon Chime]

その他

資料 読んだ  重要度 
[Cost Explorer]
[AWS Management Console]

補足

重要度の低い資料も読んだ方がいいです。
なぜなら、マネージドサービス自体がAWSの活用事例であり、それらを知ることでシステム設計の勘所が分かるようになるからです。
また、重要度の高い機能との連携についての記載があることもあり、理解が深まります。

続きを読む

AWS ソリューションアーキテクトプロフェッショナル 受けてきました&勉強法(2017/6版)

前書き

image.png

 前回 の続きです。ソリューションアーキテクトアソシエイト(SAA)に受かったので今度はプロフェッショナル(SAP)に挑戦しました。

AWS の資格試験はわかりにくい

ワークショップについて

 公式サイトから読み取れないので補足。以下のクラスがありますが、

レベル/分野 アーキテクト 開発 運用
アソシエイト取得済み Advanced Architecting on AWS DevOps Engineering on AWS 同左
アソシエイト未取得向け Architecting on AWS Developing on AWS Systems Operations on AWS
AWS 未経験者向け Amazon Web Services 実践入門 1 / 2 同左 同左

 前提事項は記載ありるものの、いきなり Advanced などを受けてもいいし、受けずに受験に挑んでも大丈夫です。アソシエイト未取得向けのを2つ受ける必要はなさそうなので、Architecting 受けてから Developing 受けたりするのは、けっこう内容の重複がある ので、お金がもったいない。
 その他のクラスは試験に出てくる頻度が低いので、興味があれば受ければいいやつです。

 ソリューションアーキテクトアソシエイト(SAA) だけは試験対策として半日のワークショップがありますので、時間とお金があれば受けるといいかと。

認定試験について

 おさらいですが。
image.png

 ワークショップと同じく、範囲がかぶっているので アソシエイト取れたらほかのアソシエイトもいけそう なので、資格の数を増やすにはよさそうです、プロフェッショナルはそう簡単にいかないですが。英語版の資格として Advanced Networking 、Big Dataが追加となっています。Security(Beta) もあった気がしますが、 Beta が取れていないのかな。いずれさらに上の階級にある Master が提供されるかもしれないという噂があったりします。

試験概要

 概要をざっくり記載します。アソシエイトの倍の時間でついでに受験料も倍です。合格ラインはやはり65%という噂です。1問あたり2分ちょっとで解き、3時間集中し続ける というなかなかヘビーな内容です。

TOPIC DATA
試験時間 170分間
問題数 80問
合格ライン 非公開
受験料 ¥32,400

出題範囲

 出題範囲を確認すると、アソシエイトでは高可用性がほとんどでしたが、Pro では求められるものが変わっていることがわかります。そのほか試験ガイドをざっと読みました。

TOPIC 出題率
高可用性および事業継続性 15%
原価計算 5%
デプロイメントマネージメント 10%
ネットワーク設計 10%
データストレージ 15%
セキュリティ 20%
拡張性と伸縮自在性 15%
クラウド移行およびハイブリッドなアーキテクチャ 10%

学習

セミナーを受講する

 前述の Advanced Architecting on AWS を受講しました。
 セミナーには AWS 社員の方や、AWS をすでに実務で利用されているかたが多くいて、私のような素人も半分くらいいる印象でした。私は実業務で AWS に触れたことが実はほとんどなく、本気の AWS 運用に必要な知識を持ち合わせていなかったので次のような観点が非常に勉強になりました。

  • ユーザ管理:IAM と ADやフェデレーションでの連携を考慮し、大規模運用を考える
  • コスト観点:一括請求やスポットインスタンスの選び方で、大幅なコスト削減を考える
  • 運用・監査:KMSを使用した暗号化、CloudLogs でのロギング、ClodWatch でのモニタリングで運用・監査への対応を考える
  • 可用性・セキュリティ:大規模&複数VPCのデザイン、MultiAZ、MultiRegion で可用性向上を実現する、DDoS からインフラを保護する

AWS 活用資料集(BalckBelt)、WhitePaper を読む

 アップデートもあるので、改めて時間を見つけて読みました。時間があるときは Webinar にも参加しました。 Webinar だと日々疑問に思っていることの質問を AWS の SA に直接質問できるので、すごくおトクです。

  • BlackBelt

    • Amazon EC2
    • Elastic Load Balancing
    • Auto Scaling
    • Amazon EC2 Container Service
    • AWS Elastic Beanstalk
    • AWS Lambda
    • Amazon EBS
    • Amazon S3
    • Amazon CloudFront
    • Amazon Glacier
    • AWS Storage Gateway
    • Amazon Elastic File System
    • AWS CloudTrail & AWS Config
    • AWS Support & Trusted Advisor
    • AWS Directory Service
  • WhitePaper

    • セキュリティのベストプラクティス
    • セキュリティプロセスの概要
    • リスクとコンプライアンス
    • AWS を用いた故障耐障害性の高いアプリケーションの構築
    • 新しいリージョンへの AWS リソースの移行
    • 災害対策目的での AWS の使用

本読む

 AWS 事例全集 といった AWS が配っている冊子もありますが数がひたすら多いので、勉強用としてこちらの本で一般的なアーキテクチャを学びました。

image
Amazon Web Services 定番業務システム12パターン 設計ガイド

試験に向けて

 以下、結果もあわせて書いていきます。

サンプル問題集にチャレンジ

ソリューションアーキテクト プロフェッショナル

 サンプル問題を解いた結果、微妙でした。アソシエイトは本試験とくらべて非常に簡単だったので、先が思いやられます。

結果

4/6問 正解

ソリューションアーキテクト以外もやってみる

 SysOpsアソシエイト、DevOpsアソシエイトのサンプル問題もやってみました。ソリューションアーキテクトとはちょっと毛色の違うサービス(CloudFormationとかSQSとか)が出てくるので復習になります。Pro は回答が書いていなかったのでやっていません。

SysOps結果

6/10問 正解

DevOps結果

6/9問 正解

模擬試験

 データ書いておきます。なお、アソシエイト合格者はバウチャーコードが利用できますので活用しましょう。問題文はコピーできます。

TOPIC DATA
試験時間 90分間
問題数 40問
合格ライン 明記なし
受験料 ¥4,320

結果

得点: 27%
結果: 不合格

 時間足りなさすぎました。結果を分析しますが全体的に悪すぎて手のうちようがない感じでした。。。

TOPIC 出題率 正解率(模擬結果) 模擬出題数(予測) 誤答数(予想)
高可用性および事業継続性 15% 33% 6 4
原価計算 5% 0% 2 2
デプロイメントマネージメント 10% 0% 4 4
ネットワーク設計 10% 50% 4 2
データストレージ 15% 50% 6 3
セキュリティ 20% 25% 8 6
拡張性と伸縮自在性 15% 16% 6 5
クラウド移行およびハイブリッドなアーキテクチャ 10% 25% 4 3

出題傾向を抑える

 ベストプラクティスが複数書いてあって、どれも正解だけどよりベストなものを選ぶという問題や、コスト/可用性/移行期間/既存システムとの連携 のどれが求められているのかといった、真の目的を把握しないと答えられない問題が多くありました。
 また、昔の AWS 構成を最新のサービスで置き換えるような問題もあるため、古くなった知識はアップデートが必要です。

模擬試験の復習と弱点克服

 CloudHSM とかの暗号化系、DirectConnect/StorageGateway などの低レイヤー系、TrustedAdvisor など課金系、STS/IAMロールなどの認証系、StepFunctions や SWF などフロー系、Redshift や Kinesis などのBigData系 は、アソシエイトでも踏み込んだ問題が出なかったので個人的に苦手でした。これらは BlackBeltで復習しました。
 また、コピーした模試の問題はを1つづつ調べ、答え合わせをしました。模擬試験については本試験でも出ることがあるので暗記するつもりで復習しました。英語で回答を解説しているサイトがあるので大いに活用しました。

本試験

結果

合格!

image.png

内訳

総合スコア: 66%

トピックレベルのスコア:
1.0 High Availability and Business Continuity: 91%
2.0 Costing: 75%
3.0 Deployment Management: 62%
4.0 Network Design: 37%
5.0 Data Storage: 91%
6.0 Security: 56%
7.0 Scalability & Elasticity: 69%
8.0 Cloud Migration & Hybrid Architecture: 28%

所感

 なんとかギリギリセーフでした。本試験、すごい疲れます。。。
 実務半年程度のペーペーなので試験勉強と実務知識が比例するわけじゃなく、試験としては問題数こなすのが一番という気がしました。本試験のほうが模試より簡単だったので絶望せずがんばりましょう。

 次は DevOps に挑戦したいです。

続きを読む

AWSコストカット大作戦

AWS


サーバ代、決して安くないですよね


学習コストも安くはない


下手すると


破産します


:banana:


現状を見直してコストカットできるかもな方法をご紹介します💰


🌏お品書き

  • コストエクスプローラー
  • Trusted Advisor
  • 一括請求(ボリューム割引)
  • S3
  • EC2

コストエクスプローラー

サービス毎に月または日毎のサービス使用量をグラフ化。もちろんサービス(EC2やRDS)毎に見れる。


Cost Reports 2017-06-02 09-09-14.png


1->2->3の順でクリックすれば見れます(3は見たいやつをクリック)

Billing Management Console 2017-06-02 09-12-47.png


コストエクスプローラーでまずは現状を把握することから始めましょう🐑


Trusted Advisor

「コスト最適化」、「パフォーマンス」、「セキュリティ」、「フォールトトレーランス」の観点からAWSが自動で精査し、推奨設定を通知してくれるサービス


Trusted Advisor Management Console 2017-06-02 09-24-22.png


  • 「コスト最適化」はダッシュボードで下記確認可能に

    • EC2 リザーブドインスタンスの最適化
    • 使用率の低いAmazon EC2 Instances
    • アイドル状態の Load Balancer
    • 関連付けられていない Elastic IP Address
    • アイドル状態の RDS
    • 期限が近づいているリザーブドインスタンス
    • Amazon Route 53 レイテンシーリソースレコードセット
    • 利用頻度の低いAmazon EBSボリューム
    • 利用頻度の低いAmazon Redshift Cluster

注意点

  • 無料で利用できるのはほんの一部の機能のみで、無料枠では残念ながらコスト最適化の項目が使いものになりません…
  • $100のアップグレードを行えば、項目が利用可能に(パフォーマンスチェックやセキュリティチェックも高機能に)

一括請求(ボリューム割引)

一括請求を使用した複数アカウントの料金の支払いでボリューム割引が適用可能


BasicDiagram.gif


VolumeDiscount.gif


データ転送量の合計やRI購入額などいろんな部分にボリューム割引がある。
個別のアカウント毎にはボリューム割引を受けられる量を使っていなくても、
一括請求を設定することで全アカウントで合算をもとにボリューム割引が受けられるようになる


S3

言わずと知れたストレージサービス


  • S3(標準)
  • S3(低頻度アクセス)
  • Glacier

違い(ざっくり)

S3(標準)->S3(低頻度アクセス)->Glacier
と右に行くほど
ストレージ価格が安くなり、リクエストや取り出し料金は逆に高くなります。


料金 - Amazon S3 | AWS 2017-06-02 13-37-59.png


  • 基本的にはS3(標準)
  • 巨大なアーカイブデータ(ログなど)はS3(低頻度アクセス)、Glacier

という運用が良さそうです。
リクエストと取り出しの料金帯が複雑なので省きます。ドキュメントを確認してください


余談

Amazon Glacierでクラウド破産しないために という記事があるので詳細は省きますが、
Glacierで100GBのファイルを復元しようとすると2万円、何かの間違いで120TBを一気に復元しようとすると2,521万円請求される計算になるらしい(旧価格ですが)


EC2

言わずと知れた仮想サーバー


リザーブドインスタンス


リザーブドインスタンスとは

  • 簡単に言うとインスタンス費用の先払いで割引が発生するサービス
  • 先払い期間は1年(平均40%割引)と3年(平均60%)の2種類
  • 最大75%OFF

  • 厳密に言うとリザーブドインスタンスの権利
  • インスタンスタイプのことではない
  • 購入したリザーブドインスタンスと同じインスタンスタイプがあれば、そのインスタンスタイプは自動でリザーブドインスタンスになる

他EC2のチェックポイント


  • 旧世代のインスタンスタイプのグレードアップ

    • 新しいほど安くて高性能(m3、m4などは数字が大きい方が新世代)
  • 開発環境/stagingの稼働時間見直し(夜間休日は止めるとか)
  • オーバースペックなインスタンスのグレードダウン検討
  • アプリケーションレベルでの転送量削減(画像・html・js・cssの圧縮、無駄なリクエストの削減など)

など


ありがとうございました

続きを読む

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から利用できるようになりました。

おわりに

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

続きを読む