AWS EC2 スナップショットの作成

スナップショットの作成

インスタンスの停止

スナップショット作成時にはインスタンスの停止が推奨されます。
AWSのコンソールもしくは、OSからインスタンスを停止させます。

使用中のアタッチ済みボリュームのスナップショットを取ることができます。
ただし、スナップショットでは、スナップショットコマンドを実行した時点で Amazon EBS ボリュームに書き込まれているデータのみがキャプチャされます。
そのため、アプリケーションやオペレーティングシステムによってキャッシュされたデータは除外される可能性があります。スナップショットを取る間、ボリュームへのすべてのファイルの書き込みを停止できれば、完全なスナップショットを取ることができます。
ただし、ボリュームへのすべてのファイルの書き込みを停止できない場合は、一貫した完全なスナップショットを取ることができるように、インスタンス内からボリュームをアンマウントし、スナップショットコマンドを実行して、ボリュームを再マウントします。
スナップショットのステータスが pending の間は、ボリュームを再マウントして使用できます。

Amazon EBS スナップショットの作成

AWS EC2 コンソールから停止する場合

Image 1.png

OSから停止する場合

sudo shutdown -h now

など

EBSの選択

AWS EC2 コンソールで画面下部に表示される「説明」からインスタンスに紐づくEBSを選択します。

Image 2.png

スナップショット作成

対象のEBSのスナップショットを作成します。
Image 3.png

Image 6.png

Image 7.png

Image 8.png

t2.small 8GiB で 5分強で作成完了でした。
開始直後に少し、進捗状況を確認したのですが0%のままで気づいたら完了していました。

復元

スナップショットをもとにイメージを作成を作成し、新規インスタンスを立ち上げます。

イメージ作成

Image 10.png

Image 11.png

作成したイメージをもとに立ち上げれば復元完了です。

引用元

Amazon EBS スナップショットの作成 – Amazon Elastic Compute Cloud
スナップショットによるEC2インスタンスのバックアップとレストア | Developers.IO

続きを読む

EBS学習メモ

この文書について

AWS EBSに関する学習メモ

https://aws.amazon.com/jp/ebs/details/

EBS

簡単なまとめ

  • SSD(io1,gp2)とHDD(st1,sc2) に大別される
  • 読み書きの瞬発力(IOPS)がほしいなら io1
  • そこそこで良いなら gp2
  • 安さと最大スループットを求めるなら st1sc1
  • io1でないEBSを使っていて、IOPSで問題が発生したら BurstBalance を確認
    • Burstしていなければ、EBS以外に問題がある
    • Burstしていれば、EBSをio1に変え、EC2もEBS最適化インスタンスにする

性能比較

ボリューム当たりの最大IOPS

io1(2万) > gp2(1万) >>> st1(500) > sc1(250)

ボリューム当たり最大スループット

st1(500MB/s) > io1(320MB/s) > sc1(250MB/s) > gp2(160MB/s)

I/O サイズとボリュームのスループット制限

  • EBSにはスループット制限がある
  • 小さいデータのI/O操作が原因で、スループット制限よりも低いデータ量でも制限が発動することがある
    • 特にSSDの場合、単一I/O とみなされるデータ量が小さい
  • スループット制限を超えてもバーストバケットを使ってカバーされる
    • バーストバケットがなくなると本当に制限される

      • CloudWatchなどでBurstBalanceを見ると状況がわかる
  • EC2 インスタンスの帯域幅が制限要因になることがある
    • 対策はEBS最適化インスタンスの利用

IPOS

  • IOPS = 1 秒あたりの入出力操作数を表す測定単位
  • 操作は KiB 単位で測定される
  • 単一I/O とみなされるデータ量はEBSがSSD/HDDによって異なる
    • 最大I/Oサイズ

      • SSD: 256 KiB
      • HDD: 1,024 KiB
    • SSDでは1つのIOとみなさるサイズが小さい
      = I/O やランダム I/O の処理が HDDより効率が良い

EBS最適化EC2インスタンス

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html

  • io1 は EBS最適化EC2との併用が推奨
  • EBS最適化EC2インスタンスの特徴
    • Amazon EC2 と Amazon EBS の間の専用スループットがある

      • Amazon EBS I/O と EC2 インスタンスからの他のトラフィックとの競合を最低限に抑える
      • 専用スループットは500Mbps~10,000 Mbps
        • インスタンスタイプに応じて変化
  • EBS最適化インスタンスが使えるEC2 (2017年10月現在)
    • c系 (c1, c3, c4)
    • d系 (d2)
    • f系 (f1)
    • g系 (g2, g3)
    • i系 (i2, i3)
    • m系 (m1, m2, m3, m4)
    • p系 (p2)
    • r系 (r3, r4)
    • x系 (x1, x1e)

続きを読む

EBS新機能エラスティックボリュームをすぐに本番反映をトライしてみたらダメだったけど、AMI使えばできたのでストーリー仕立てで書く

これをやった理由

  • 本番のWEBサーバやバッチサーバで、Full Data Diskアラートが頻発するため

    • 頻度は週に1度
    • 原因は、担当システムで登録時にアップロードされたファイルのS3からのダウンロードとサムネイルの生成を大量にやるため

参考資料

対応方法

  • 下記の参考資料のまんまです。
  • やってみて経過を追ってみようと思ったけど、、、うちで使っているインスタンスがEBSが古すぎて対応してないみたい・・・ :sweat_smile:

8196b955-dfa0-4843-1bca-a02ed0a40d67.jpeg

おわりw

AMIからインスタンス再作成してやってみた

AMIから作り直してからだと、怒られなかったよー

8ed3b9e0-cbde-722e-e1cf-5a274aad39b7 jpeg.jpg

ってことでやってみます。とりあえず変更前が下記。

before
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       7.9G  5.8G  2.1G   75% /
devtmpfs         7.4G   44K  7.4G    1% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm

OK押したら、こんなん出てきた。。。けど、とりあえず「Yes」押す。
変更中は、一時的にパフォーマンス落ちるよってことだと思われます。

b5dd5bb4-7384-a197-4ba2-03e8c0759d26 jpeg.jpg

んで、ポチったらこうなるみたい。

7b76b2a5-5fc8-9ef8-5f21-74dd7042ecf2 jpeg.jpg

約5分から7分程度待ちましたら、こうなりました。

7efacdbc-6a32-9d36-aad8-a07b72d8e627 jpeg.jpg

ってことで、もっかいストレージ見てみます。
が、、、あれ、変わってない・・・

after
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1       7.9G  5.8G  2.1G   75% /
devtmpfs         7.4G   44K  7.4G    1% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm

ここを見るとまだ何か必要っぽい、、、
Amazon EBSのアップデート – 新機能エラスティックボリュームが全てを変える | Amazon Web Services ブログ

次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。
作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するかWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。
ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。>新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。>コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。

ストレージ領域は変更かかったけど、ファイルシステムを拡張する必要があるとのことでした。
なので、下記のページを見て、コマンド打つみたい。
Linux ファイルシステムを拡張するのとこを参照。
Linux で EBS ボリュームのストレージ領域を拡張する – Amazon Elastic Compute Cloud

ファイルシステム確認
$ sudo file -s /dev/xvda1
/dev/xvda1: Linux rev 1.0 ext4 filesystem data, UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (needs journal recovery) (extents) (large files) (huge files)

次に、Linux ファイルシステムを拡張するにはのとこを見て、ファイルシステム拡張すると、できました!
おーーー!結構簡単でうれしい :smile:

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

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/xvda1        20G  5.8G   14G   30% /
devtmpfs         7.4G   44K  7.4G    1% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm

以上。これなら、一時的にELBからインスタンス切り離して対応後に再接続って形でオンラインでできちゃいますね!

続きを読む

Amazon WorkMail – WEBインフラに不要な穴を開けないために

概要

Amazon EC2 でインターネット向けにWEBサーバーを運用している場合、よくある仕様追加「このドメイン名でメール送受信したい」に対応。
Amazon EC2 からのメール送受信は公式では非推奨 1
「安いは正義」に「WEBインフラにメールサービスを上乗せするなんて」で立ち向かう方への処方箋。

前提

  • ドメイン名(例えば example.tld)は既に取得済み、利用可能状態と仮定します。
  • 実現までのプロセスはすべて AWS リソースを使います。
  • ディレクトリーサービスの既存利用なしと仮定します。(お金なくて検証できてない)

AWS リソース

AWS 製品

既存のディレクトリーサービスが存在せず Amazon WorkMail をミニマムスタート、かつ、AWS サービス内で完結する場合には以下が必要になります。
1. Amazon VPC
2. AWS Directory Service
3. AWS Identity and Access Management (IAM)
4. Amazon WorkMail
5. Amazon Route53

AWS リージョン

Amazon WorkMail は、2017年8月現在、以下のリージョンで提供されています。

Code Name
us-east-1 US East (N.Virginia)
us-west-2 US West (Oregon)
eu-west-1 EU (Ireland)

Amazon WorkMail を利用するリージョンで Amazon VPC ならび AWS Directory Service を利用開始する必要があります。

費用計算

請求金額見積もり

  1. Amazon VPC
    今回のケースでは費用発生しません。
  2. AWS Directory Service
    Amazon WorkMail にて Simple AD を利用する場合に限り無料となります。2
  3. AWS Identity and Access Management (IAM)
    今回のケースでは費用発生しません。
  4. Amazon WorkMail
    1ユーザーあたり1ヶ月につき 4 USD。
  5. Amazon Route53
    1ホストゾーン(ドメイン名)につき 0.50 USD/月
    100 万クエリにつき 0.400 USD

損益分岐点

Amazon WorkMail と Amazon EC2 (t2.medium) を12ヶ月運用で比較してみます。(US East (N.Virginia))

Products type price
Amazon EC2 t2.medium のリザーブドインスタンス(1年全額前払) 約 22.91 USD/月
Amazon EBS gp2 50GB 5 USD/月
Amazon WorkMail 6ユーザー 24 USD/月
Amazon WorkMail 7ユーザー 28 UDS/月

6ユーザーより大きなユーザー数で運用は Amazon EC2 リザーブドインスタンスの方が費用的に安価になりますが、これには冗長性等、考慮されていません。
耐障害性、可用性から考えても、この要件が発生した際には Amazon WorkMail を選択がベストプラクティスと言えます。

オペレーション

ドメイン名 example.tld によるメール送受信を実現するために以下を行います。

  1. Amazon VPC
    • Simple AD 稼働のための Subnet を用意
  2. AWS Directory Service
    • Simple AD によるディレクトリー作成
  3. AWS Identity and Access Management (IAM)
    • 保管メールデータ暗号化に使用するキー管理のために AWS Key Management Service (KMS) を設定
  4. Amazon WorkMail
  5. Amazon Route53
    • ドメイン名 example.tld のDNSレコード管理

Amazon VPC

デフォルトで用意されている VPC と Subnet でも開始可能ですが、Simple AD で利用する Subnet は public subnet である必要はありません。
private subnet (Route Table に Destination: 0.0.0.0/0 が存在しない、またはそれ以外)で可能です。
以下成果物です。要望あればキャプチャー添付。TBC。

Name IPv4 CIDR Availability Zone
simplead-a 10.0.0.0/28 us-east-1b
simplead-b 10.0.0.16/28 us-east-1e

AWS Directory Service

AWS Management Console より AWS Directory Service を選択し、Simple AD をセットアップします。
年々 Simple AD と AD Connector の取り扱いがざつにn……

セットアップ情報は例えば下記です。要件に合わせて読み替えます。

Directory details

Name Value remarks
Directory type Simple AD 固定値
Directory DNS ad.example.tld
NetBIOS name オプション・未記入
Default administrative user Administrator 固定値
Administrator password ********
Description オプション・未記入
Directory size Small

VPC Details

Name Value
VPC 10.0.0.0/16
Subnets simplead-a, 10.0.0.0/28, us-east-1b
simplead-a, 10.0.0.16/28, us-east-1e

Access URL

セットアップ完了後、Status: Creating から Active になれば利用可能です。
この時、Access URL を定義します。
これは Amazon WorkMail の Web メールのURLで利用します。
例えば example.awsapps.com です。

AWS Identity and Access Management (IAM)

保存されるメール暗号化のため、暗号キーを指定します。
ここではデフォルトの aws/workmail を使います。

Amazon WorkMail

上記までに事前準備が完了しているはずですので、ここでは Standard setup でセットアップします。

Organizations

セットアップ情報は例えば下記です。要件に合わせて読み替えます。

Name Value remarks
Available Directories ad.example.tld セットアップした Simple AD
Master keys aws/workmail セットアップした KMS

Create 押下後、Status が Creating から Active に変われば利用可能です。

Domains

セットアップした Organization のドメイン名を定義します。
Organization のナビゲーション Domains を押下してドメイン名を定義します。
ここで先に設定した Access URL(example.awsapps.com)も確認できます。

Amazon SES と同様、ドメイン名の確認(Verify domain)が必要になります。
次項の Amazon Route53 の Hosted Zone (example.tld)に表示される下記のDNSレコードを追加します。

Recode type Hostname Value remarks
TXT _amazonses.example.tld. (指定された文字列) Domain verification で利用します
MX example.tld. 10 inbound-smtp.us-east-1.amazonaws.com. 3
CNAME autodiscover.example.tld. 3
CNAME (指定された文字列)._domainkey.example.tld. (指定された文字列) DKIM セットアップ4

Users

同じく Organization のナビゲーション Users よりユーザー定義を行います。
ユーザー名、パスワード、メールアドレスを入力してセットアップします。
特記する箇所はないため、ここでは割愛します。

Amazon Route53

Amazon WorkMail のセットアップ、Domains で得たDNSレコード情報を Hosted Zone example.tld に登録します。
割愛します。

上記にて username@example.tld によるメール送受信が可能です。

クライアント

デスクトップ、モバイル

Microsoft Exchange ActiveSync プロトコルをサポートするので、以下のデスクトップ、モバイルのクライアントに対応。
– Mac Mail.app
– iPhone
– Outlook
その他要検証。TBC。

ウェブアプリケーション

AWS Management Console, Amazon WorkMail のナビゲーション Organization settings で用意されている Web Application https://(文字列).awsapps.com/mail よりログイン可能。5

その他留意事項

申請関連

サービス上限

以下、気をつけるべき箇所の抜粋です。

  • 1ユーザーのメールボックスは 50GB
  • 送信・受信ともに1メールは 25MB
  • 1 日のユーザーあたりのメッセージ送信数 宛先に関係なく、1,000 件のメッセージ
  • ユーザーのエイリアス(アドレス)は 100(ハードリミット)

Amazon SES

メール送信は Amazon SES 経由で送信されますが、WorkMail からの送信は課金対象となりません。
また API 経由では必要な送信制限解除申請(サンドボックスから取り外す)も必要ありません。

未記入事項

以下の機能については記載してません。to be continued.

  • 移行
  • ジャーナリング
  • フロールール
  • グループ、リソース
  • 既存AD連携

出典

いつの日も AWS ドキュメントと FAQ は最強説。

続きを読む

実務経験がなくても2ヶ月でAWSソリューションアーキテクトに合格するためにやったこと

ゴールデンウィークくらいからAWSを趣味で触り始めてちょっと面白そうだったので、ソリューションアーキテクトの試験を受けてみようかと思い立ちました。
2017年7月12日になんとかギリギリ69%で合格できていたのでどういう風に勉強していったのかを残してみます。
なお、Qiitaには初投稿になります。

まずAWSに触り始める前事の自分自身の知識としては

  • 普段はエンプラ系の製品開発に従事
  • IPAのネットワークスペシャリストとデータベーススペシャリストを保持
  • AWSの主要サービスがなんなのかくらいはうっすらとわかる
  • たまにAWS関連のニュースを見てる
  • 実務でのAWSの経験は今まで全くない(そしてこれからもなさそう…

という感じでした。

自分としてはネットワークやデータベース周りの基本的な知識はある方だと思っています。
しかし、実際のお仕事ではクラウドのクの字にもかすりもしない、全く縁がない分野の人間です。

また、平日はあまり勉強することはなく(Evernoteに記録したノートを読み返す程度)、主に土日のみ勉強していました。実際には休みの日に4~5時間程度だったと思います。

アカウントを作成する

なにはともあれまずは無料枠を全力で駆使するためにアカウントを作成しました。とはいえ最初は何からやって良いのかわからないので、ざっとチュートリアルを触ってみました。

AWS 10分間チュートリアル

ほんとに10分だけでいろいろと体験できるのでありがたいです。
チュートリアルでは途中でつまづくことものほぼありませんでした。
チュートリアルとしてはとても役に立ったと思います。

試験ガイドを見てみる

AWSソリューションアーキテクトの右側にある試験ガイドのダウンロードからダウンロードして試験の範囲などを確認しました。特に製品名が明示的に書かれているものは重点的勉強する必要があると感じました。

セキュリティの基本的な考え方を知る

セキュリティプロセスの概要を読んで共有責任モデルを始めとする考え方を知っておきます。ページ数が結構あります。

サンプル問題をやってみる

AWS 認定ソリューションアーキテクト – アソシエイトの右側にある[サンプル問題のダウンロード]からダウンロードして解いて見ました。最初には全然わかりませんでした…

AWSのドキュメントを見てみる

基本的には勉強といってもAWS ドキュメントをひたすら読むということが大半でした。あとはAWS用語集も割と目を通しました。
さらに、AWSクラウド活用資料集も必要そうな製品のものについては一通り目を通しました(その内リンク切れしそう…)。
また、よくある質問は確実に目を通しておいたほうが良いと思います(特にページの上の方にある質問。下の方はより細かい質問に対する解答になっている気がしてあまり読みませんでした)。
以下のドキュメントはだいたい目を通しましたが、応用っぽい使い方などについてはあまり深追いはしませんでした。

重要そうな項目や説明はEvernoteの方に残してマーカなどで印をつけていきました(上記だけでも結構な分量になりました)。
上記の製品をいかに組み合わせて問題を解決するのかといった視点が重要になるようです。

AWS Summit 2017に参加してみる

1日だけでしたが、入門系のセッションだけ参加してきた。過去の分も含めて後からPDFでも動画でも確認できるのは非常にありがたいです。モチベーションも上がりました。

AWS Summit Tokyo 2017 セッション資料・動画一覧

また参加していて思ったこととしては、最新情報はある程度キャッチアップしておく必要があると思いました。例えば、「既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました」のように、今までできていなかったものができるようになったのはよくチェックした方が良いと思います。

書籍関連

書籍としては以下のものを読んで、その内のいくつかは実際に書籍の従って動かしてみたりもしました。
たまたまKindle版が半額になっていたものやポイントが多かったりすることもあって購入もしています(運が良かった…)。
購入していないものは図書館で借りて2週間(図書館の期限が2週間なので)で隅から隅まで熟読してました。
実務経験がない以上、とにかく手を動かしていくことが重要だと考えました。

いろいろなリンクを回ってみる

クラスメソッドさんのブログは情報も早くてよく見てました。他にもAWS公式ブログやqiitaの記事なども目を通していました。特にQiitaのソリューションアーキテクトに合格した系の記事は大変参考に、かつモチベーションの維持に効果がありました!

Amazon Web Services ブログ
Developers.IO
Qiita -ソリューションアーキテクト-

また、以下のサイトでは実際に試験のような問題を解くことができます。有料なところもあるので、やるかどうかは自己判断になります。

AWS Web問題集で学習しよう

あまり深く勉強しないものを知っておく

「この製品はなんですか?」「この製品で何ができますか?」くらいの知識でも大丈夫そうなものについては、あまり深く勉強しないようにしました。例えばRedShiftやKinesis、OpsWorkなどがそれに当たるかと思います。
また、SDKやコマンドラインツールなどについては範囲外だと思うので一切見ていません。

模擬試験を受けてみる

1週間前くらいに模擬試験を受けてみた結果、70%でした。
模擬試験は本試験の半分くらいのボリュームでしたが、それでも結構難しく感じました。
マークをつけることで後から見直すことができるので、ちょっとでも不安な問題にはマークをつけて復習できるようにメモっておきました(試験が終わると問題文などに確認はできなくなります)。
この時点ではちょっとまだ本番に自信がなかったので、ここから本試験まではあまり手を動かさずに、ここまで勉強したことの復習をメインに、Evenoteを読み返したりドキュメントの再確認をやり始めました(この時点で書籍はほぼ読了済みの状態)。

実際の試験のときの心構え

試験は午前中にして朝早めにおきて、現地には早めにいき近くの喫茶店で最終確認をしておきました。
本試験では、とにかく問題文をしっかりと読むこと大切だと感じました。
また、ちょっと引っ掛けのようなものも混じっていたりして、うろ覚えではなくキチンと理解することが重要だと感じました。

最後までやってみたところで時間は結構余ったので、読み返しに結構時間が使えました。
採点結果としては実務経験がないこともあって、トラブルシューティングの得点はやはりよくありませんでした(なんと33%…)。
ここはやはり経験が生きるところなのだと思いますが、ドキュメントのトラブルシューティングをもっと読み込んでおけば良かったと後悔しています。

今後

趣味で終わらせるには勿体無い分野だと思うので、クラウド絡みのお仕事したいけど今のところじゃまずそんな仕事はないという…
でもプロフェッショナルもいずれはとってみたいので、やはり実務経験が欲しいところです。

続きを読む

AWS概要

AWSについてこれから学んでいくのでその勉強内容をまとめていく。

1.AWSとは

AWS(Amazon Web Service)とはオンラインショッピングで有名なAmazonが提供するパブリッククラウドサービス。
サービスの豊富さと提供スピードの速さが特徴。

1.1アマゾンが提供するサービス

AWSでは多くのサービスが提供されているが、そのサービスを分類ごとに大別し、代表的なものを紹介する。

  • コンピューティング
  • ストレージ&コンテンツ配信
  • データベース
  • ネットワーク
  • 開発者用ツール
  • 管理ツール
  • セキュリティ&アイデンティティで
  • 分析
  • IoT
  • モバイル
  • アプリケーションサービス
  • エンタープライズアプリケーション

1.1.1 コンピューティング

AWSの中核となるサービス。
AWS超初心者の私でも聞いたことがあるEC2もここに分類される。

・EC2(Amazon Elastic Compute Cloud)

従課金性(使った分だけお金を払う)の仮想サーバ。
OSはLinuxやWindowsが用意されている。
EC2を活用してDockerを運用したりDockerイメージの保存・共有を行うサービスも提供されている。

・AWS Elastic Beanstalk

Paasサービス。
これを利用すれば.NETやPHP、Python、Ruby、Node.jsで開発したアプリをAWSに自動でデプロイできる。
例えばJavaアプリの場合はEclipceで開発してEC2に配置するというところまでを自動でやってくれる。

・AWS Lambda

クライアントからリクエストが来た時だけ動くイベントドリブン型のサービス。
EC2と違って常時起動しているわけではないので低コストで運用できる。

・Auto Scaling

CPU使用率などの条件に応じてEC2を拡張するサービス

・Elastic Load Balancing

負荷分散させるロードバランサのQWSバージョン。

1.1.2 ストレージ&コンテンツ

・Amazon S3

オンラインストレージサービス。

・Amazon CloudFront

世界中にコンテンツを配信するためのネットワークサービス

・Amazon EBS

EC2のデータを保持するストレージサービス。
EC2のHDやSSDのような役割。
EC2のインスタンスタイプがc4やM4だとストレージはこのEBSのみ。
EBSは確保した容量の分だけ料金がかかるので容量が大きいファイルを扱うときは注意が必要。

・Amazon Elastic File System

EC2の共有ファイルストレージサービス。
使用容量の増減に伴って自動で拡張/縮小する。

・Amazon Glacier

バックアップファイルなど、使用頻度は低いけど長期間保持しておきたいデータ向けの低価格ストレージサービス。

・AWS Import/Export Snowball

大容量データ転送サービス。
ペタバイトレベルのものでも転送可能。

・AWS Storage Gateway

オンプレとAWSを接続するGW

1.1.3 データベース

・Amazon RDS

RDBMSを運用するサービス。
MySQLやOracle、SQLServer等が運用可能。

・AWS Database Migration Service

データベース移行サービス

・Amazon DynamoDB

noSQLの構築/運用サービス。
noSQLとはビッグデータなどで使用されるDBMS。

1.1.4 ネットワーク

・Amazon VPC

AWS内にプライベートネットワークを構築するためのサービス。

・AWS Direct Connect

オンプレのネットワークとAWSのネットワークをつなぐためのサービス。

・Amazon Route 53

DNSシステムを構築するためのサービス。

1.1.5 開発者用ツール

・AWS CodeCommit

Git等のバージョン管理ツールを運用するためのサービス。

・AES CodeDeploy

開発したアプリを自動でデプロイするサービス

1.1.6 管理ツール

・Amazon CloudWatch

サーバ・ネットワークの状態をグラフィカルに確認できたり設定した閾値を超えたときにアラートを出すことができるサービス。

・AWS CloudFormation

テンプレートと呼ばれるファイルを作成することでAWSで構成するインフラ環境を自動で作成するサービス。

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

IAM(AWS Identity and Access Management)

ユーザ認証などの認証機能を提供するサービス。

分析

Amazon EMR

ビッグデータの分散処理フレームワークであるApache Hadoopの実行基盤

Amazon Machine Lerning

データを基に機械学習をするサービス。
AIなどの研究に使われる。

IoT

AWS IoT

AWSとデバイスとの接続、ネットワーク管理、セキュリティ、データベースとの接続を提供するサービス。

モバイルサービス

Amazon Cognito

アカウント管理・認証、データ同期などを行うサービス。

AWS MobileSDK

OSに合わせた開発ツールを用意するサービス

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

Amazon SES

Emailの送受信サーバ

・Amazon Cloud Search

クラウド内のデータ検索を行うサービス。

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

・Amazon WorkSpaces

デスクトップPCをクラウド上で実行するサービス。


ざっとまとめただけでもこの量。。。
全部のサービスの内容を理解するのは無理かもしれないけど
何かやろうとしたときにそういえばAWSにこんなサービスがあったような…
と思い出して選択肢の一つに入れれるようになりたい。

続きを読む

パーティションされていないマウントされている 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の活用事例であり、それらを知ることでシステム設計の勘所が分かるようになるからです。
また、重要度の高い機能との連携についての記載があることもあり、理解が深まります。

続きを読む