AWS利用時に最初にやっておくべき5つのこと(ShanonAdventCalendar2016 - 16日目)

こんにちは、生産性チームのkmt です。

# この記事は、ShanonAdventCalendar2016 16日目の記事です。

最近はQAの活動ではなく開発の生産性をあげる為の活動に多く取り組んでいます。
今現在は開発チームで使用しているAWSのコスト削減を行っています。

AWSはとても便利ですが、何も考えずに利用しているとちりつもで、いつのまにか結構な課金額になっていて顔が真っ青になることがあります。
世の中には既にAWSを便利に使うためのノウハウがたくさんありますので、ここではAWSを利用する際に最初にやっておくべき５つのことをお伝えできればと思います！

◆利用したいサービスとそれにかかるお金を洗い出そう

AWSにはたくさんのサービスがあります。

まずは利用したいサービスを洗い出し、そのサービスの利用金額を頭にいれておきましょう。

それがイメージできたら、あとはいかに課金を減らすかを考えていくだけです！

利用金額については各サービスごとに料金表が書いてありますので、まずはそれを目安にします。

たとえば、EC2ですとコチラから見ることができます。

既に利用を開始している場合は、AWSコンソールの請求書ダッシュボードの請求書やコストエクスプローラーから課金額を知ることができます。また予算を立てる場合は、予算機能を利用したりすることもできます。

◆なにはともあれIAMによる権限管理

まずは権限管理をしましょう。
ここでやってはいけないことは、

　　フルアクセス権をふること！

です。
誰かがハイスペックなEC2をたてたり、必要なEC2を間違って消したりすることがあるかもしれません。
またセキュリティ的にもオススメできません。

　　必要な人が必要なぶんだけ必要なリソースにアクセスできること

を考えて権限管理していきます。

AWSにはIdentity and Access Management（IAM）という機能があり、これを利用します。
Amazonのユーザガイドより

ユーザ --- AWSコンソールにサインインしたい場合や、AWSサービスに対してプログラムによるリクエストを行う場合に使用します。

グループ --- IAM ユーザーの集合です。グループを使用して、ユーザーの集合に対してアクセス権限を指定でき、ユーザーのアクセス権限を容易に管理する為のもの。

ロール --- 認証情報（パスワードやアクセスキー）を関連付けることができないアクセス権限です。アクセス権限ポリシーが関連付けられている AWS ID であるという点で、ユーザーと似ています。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。

ポリシー　--- 「どのユーザ」が「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」を記述するためのものです。AWSが提供してくれているJobFunctionという特定の職務機能と密接に連携するように設計されたポリシー、AWS管理ポリシーと自分で詳細に設定ができるカスタマー管理ポリシーがあります。

ポリシーを作成しておき、グループに紐付け、そのグループをユーザが利用するような王道の利用方法から特定のユーザにインラインポリシーという個別ポリシーを記述することもできます。またロールはLamda等のサービスを利用する際に使用できます。

◆リソースのバックアップを取ろう

利用したいサービスとユーザー、お金がイメージできたところで、次は各サービスで利用するリソースのバックアップについて考えます。
せっかくAWSを利用したけれど、環境を壊した場合にすぐに復旧できる仕組みを準備しておかなければAWSの利用メリットがなくなってしまいます。

ここでは例としてEC2利用時のバックアップについてふれてみたいと思います。

EC2サービスには

　　　　EC2　--- 仮想サーバ
　　　　EBS --- EC2に紐付けるストレージ
　　　　スナップショット --- EBSのデータをバックアップしたもの(S3におかれる)
　　　　AMI --- マシンイメージ

があります。

基本的に環境を利用する場合は、仮想サーバであるEC2に必要な分だけのEBSボリュームをアタッチすることで環境を作成することができます。

ただ、

　　EBSを壊してしまったり
　　ある時点でのEBSの状態を保持しておいて、うまくいかなければ戻したい

というような場合は、スナップショットをとっていればすぐ復元できますし、

　　EC2自体がうまく起動できない場合にもう一回EC2を作り直したい

　　EC2インスタンスを複数たてたい

といった場合には、AMIをとっていればすぐに対応することができます。

ですので、復元したいインスタンスはAMIやスナップショットのバックアップをとっておくことをオススメします。

バックアップをとる具体的な方法としては

あるサーバからaws cliを使ってスクリプトを書いてcronで定期バックアップをとる
Cloud WatchのEventスケジュールで組み込みターゲット(Built-in target)を利用する
Lamdaでboto3等を利用してスクリプト書き、Cｌoud WatchのEventスケジュールで定期バックアップをとる

などがあります。

1で実施してしまうとサーバ管理やキー管理が複雑になってしまう
2で実施してしまうとボリュームIDの指定が必要なためボリュームが多い場合や変更に対応できない

ので

3のLamdaでboto3を利用してスクリプトを書き、Cloud Watchのスケジュールで定期的にバックアップを取る方法がおすすめです！

ちなみに　boto3　の EC2 にはClientである　boto3.client　と　Service Resourceである　boto3.resourceの2つがありますので使用する際にはご注意ください。

◆ゴミを残さないようにしよう

バックアップがとれた後には、ゴミがたまらない仕組みを考えなければなりません。バックアップばかりとっていてゴミを消さなければどんどん課金額が膨れてしまいます。

ここでは例としてEC2削除時のゴミ問題についてふれてみたいと思います。

念のためにおいておきたいEC2はAMIにする
EC2のEBSボリュームよりもAMIのスナップショットのほうが課金額が安いです
EC2を削除する場合には、紐づいているEBSを自動的に削除するようなオプションを設定しておく
EC2インスタンス削除時にEBSボリュームが削除されるかどうかは、Delete on terminationの値によって決まりますのでここの値を削除にするようにしておきましょう
AMIを削除した場合には、紐づいているスナップショットを自動的に削除する
Lamdaでboto3を利用してAMIに紐づくスナップショットを削除するスクリプトを書きます。Cloud WatchのEventでAMIの登録解除をトリガーにして先ほどの削除スクリプトを呼び出します

◆運用ルールをドキュメントにまとめて周知しよう

最後に運用ルールをまとめて、メンバーに周知します。
自分の組織にあった権限を付与し、それにともなった運用ルールを明記しておけば、メンバーも快適にAWSが利用できます。
また、各リソースにTagをつけておけば、どんな開発にどれくらいのリソースを割り当てていてどれくらいのお金をつかっているかを取得しやすくなります。課金レポートを作成する際に有用です。
ドキュメントを作成しておけば、運用者が変わった場合にも大きな問題なく運用ができると思います。

いかがでしたでしょうか？
ざっと説明しましたがAWS利用時にこれらのことを最初に考えておけば、後の運用がずっと楽になります。

便利なAWSサービスを利用して快適な開発をしていきましょう！

SHANON Engineer's Blog