dots.女子部 Advent Calendar 2016の15日目担当のぼへぼへです。
@sao_rio さん、漫画を読んでいただいていて、ありがとうございます！

さて、アドベントカレンダー何書こうかと迷って、今年のまとめとして、初めてAWSを仕事で使う機会ができて、いろいろと経験したことのTIPSをまとめてみました。

年の初め

JAWS-UG CLI専門支部との出会い

いきなりCLIですが・・・・
この頃フリーランスとして、コワーキングスペース茅場町Co-Edoを利用していて、ここで、隔週月曜にJAWS-UG CLI専門支部が開催されていました。
そこで、たまたま夜の時間までいたので、試しに出てみようかな、と思って出たのがきっかけでした。

この専門支部では、AWSのサービスの一つを取り上げて、その概要の説明後は、みんなでハンズオンという形式。Qiitaに毎回、細かいハンズオンの説明が載っていて、（これがすごい詳細で分かりやすい！）それをひたすらコピーペーストで実行します。

え？それだけ？って思うことなかれ。

習うより、慣れろ。

という部分を強化してくれます。そして、GUIでは見えない、サービスの設定値をCLIで見ることによって、より理解が深まります。
私は、最初はGUI中心だったのですが、この設定はどうなっているのだろう？とか思ったりした場合はCLIで参照することで、すんなりとできるようになりました。

この勉強会に数回出ているうちに、CLIで操作する一連の流れに慣れてくるので、ターミナル操作がそもそも苦手だな、と思っている人も積極的に出てみて、まずは慣れるところから始めるのにオススメです。

毎回扱うサービスも変わりますし、時にAWSのSAさんが概要説明に来てくれたりという贅沢な勉強会でもあります。

開催予定イベントリスト - JAWS-UG CLI専門支部 | Doorkeeper

docker-machineとして使っていたEC2

さて、AWS使い始めといえばEC2インスタンスですが、最初はEC2じゃなくてもいいじゃんという使い方をしていました。
そう、docker-machineです。

以下のようなシェルを準備しておいて

docker-create-virgina.sh
#!/bin/bash

if [ $# -ne 2 ]; then
    echo "docker-create-virgina instance-type name" 1>&2
    exit 1
fi

docker-machine create --driver amazonec2 \
    --amazonec2-access-key XXXXXXXXXX --amazonec2-secret-key XXXXXXXXXXX \
    --amazonec2-security-group docker-machine \
    --amazonec2-vpc-id vpc-fXXXXXXX \
    --amazonec2-subnet-id subnet-XXXXXXXX \
    --amazonec2-region us-east-1 \
    --amazonec2-zone b \
    --amazonec2-instance-type $1 \
    $2

ターミナルから実行して、docker-machineを稼動させて、開発環境として使っていました。

./docker-create-virgina.sh　{instance-type}  {name}

長いコマンドはシェルにしておくと便利ですよね。

Qiitaに手順を残してありました。
Docker環境をEC2でアップして開発環境をつくる - Qiita

春

思ったように仕事も取れず、今やっている仕事なくなったら、フリーランスという名のニートですよね、と思いつつ過ごす切ない春でした。

まずはネットワーク

Amazonには、もともとデフォルトVPCが用意されていますが、実際にサービスを構築する際には、セキュリティやアクセス経路を考えなくてはいけません。

VPCを用いる事でネットワークをプライベートに作成したり、IPアドレス等でのアクセス制限やプロトコルの制御等、セキュリティ上の要件をまとめて設定する事が可能です。

コラム - 知っておきたい Amazon Web Services のキホン | 第2回　AWSの仮想データセンタ「VPC」を理解する｜CTC教育サービス研修/トレーニング

でも、一体どういう手順で構築すれば・・・という時は、「Amazon Web Services パターン別構築・運用ガイド　一番大切な知識と技術が身につく」という書籍がとても参考になりました。
ここで「Chapter2-4 VPCネットワークの作成」、「Chapter3-1 EC2を利用した動的サイトの構築」に一通り以下の手順があるので、一度手を動かしてみると、なるほど！と理解できます。

VPCの作成
パブリックサブネットとプライベートサブネットの作成
インターネットゲートウェイの作成
ルートテーブルの作成

私の例

10.1.0.0/16でVPCを作成して、サブネットを以下のように組みました。
リージョンは東京です。アベイラビリティゾーンも分けて、どちらかがダウンしても大丈夫なようにしています。

Subnet	Name	AZ	kind
PublicSubnetA	10.1.11.0/24	1a	DMZ
PublicSubnetB	10.1.12.0/24	1c	DMZ
PrivateSubnetA	10.1.51.0/24	1a	Private
PrivateSubnetB	10.1.52.0/24	1c	Private

NATゲートウェイ・・・

プライベートサブネットにした場合、プライベートサブネット内はインターネットには接続していないゆえ、一つ困ったことが起きました。
当然といえば、当然なんですが、yum installができない、とかです。
インターネットから、入ってきてほしくはないけど、インターネットにとりにいかなきゃいけないのでNATゲートウェイを設置してあげましょう。

ちなみに、NAT ゲートウェイを作成するには、NAT ゲートウェイの常駐先のパブリックサブネットが必要となります。というか、NATゲートウェイはパブリックサブネットに立てましょう。（プライベートに作ってしまってハマった人）

初夏とともに起業

AWSとは関係ないのですが、6月10日にFirstFourNotes,LLCとして、会社を始めました。
夏の期間は、起業の事務処理やらなんやら＋この時期は主にフロント側の開発案件をしていたので、AWS関連の仕事はおやすみしていました。

秋の訪れとともにECS

さて、dockerは単一ホストの時はいいのですが、マルチコンテナ、マルチインスタンスにして、スケールさせたい！というのがあったので、この頃docker-swamを使うか、ECSを使うかと色々と検証していましたが、ECSの方がハンドリングしやすいなという感触だったので、ECSを使い始めました。

ちょうど、この検証を始めたのが10月ごろだったのですが、re:invent前後でかなりECSの機能がアップデートされましたよね。。うれしいアップデートが多かったのですが、あれ？２ヶ月前に見たのと違う・・っていう戸惑いが現在隠せませんw。

使いやすくなったECSとタイミングよく出てくれたALB

12月現在、クラスターを立ち上げる時に、クラスター内に立ち上げるインスタンスも指定できるようになりましたね。
10月ごろに、クラスター作ったはいいけど、インスタンスとか、AutoScaleとかどうするの？とかドキュメント読み漁ったのが嘘のような気がするのは私だけでしょうか。。。

さて、実際のECRの立ち上げについては、dosts女子部アドベントカレンダー1日目で、@bboobbaa さんが書いてくれていますので、こちらを参考にしてください！

ECSで上げたコンテナは本当にVPC上インスタンスのサブネットやセキュリティグループ適用されるのか？ - Qiita

タスクに対する適正なRoleの設定について

AWSの認証情報をコードの中にゴリゴリ書くのってちょっと・・・なので、ECSのタスクに適正なタスクを付与してあげるとそんなことは必要ありません。

ECSのタスクに適正なロールを付与して、実行させるって具体的にどうするの？っていうのが、以下のデモンストレーションに書かれていて、一度やってみると、なるほどと体感できました。

ECSタスクのためのIAMロールによってコンテナ利用アプリケーションをより安全にする | Amazon Web Services ブログ
- このデモンストレーションはの内容は、「Amazon S3バケットを作成し’Hello World’ファイルをアップロードするだけの簡単なNode.jsアプリケーション」です。

基本、上記のデモンストレーションの流れに沿ってやればOKなのですが、幾つか前提となっている知識があるので、そこでつまづくことがありました。

クラスターにEC2インスタンスを作成するってどうするの？
- 12月現在のGUIでは、クラスター作成時にインスタンスタイプを選択して、すぐに用意できるので問題ないかと思います。10月頃に試した時はクラスターは作成できたけど、EC2インスタンス追加するのどうするの？という状態だったので、詰まりました。その時に参考にしたのはこちらでした。　→　Launching an Amazon ECS Container Instance - Amazon EC2 Container Service
タスクのためのIAMロールの作成ってどうするの？
- IAMを選択して、ロールの作成で、AWS Service Roles では Amazon EC2 Container Service Task Roleを選択、Attach Policy画面ではAmazonS3FullAccessというIAM管理ポリシーを選択します。

ECRではなく直接docker-hubにあるものを使いたい場合

ちょっとした動作テストの時は、docker-hubにあるものを使うこともできます。
タスク定義の作成のコンテナの追加の、イメージのところに、docker-hubにあがっている名称＋versionでOKです。

ポートの設定

コンテナ追加時のポートの設定ですが、（紐付けを行うEC2ホストのポートと、コンテナ側のポートを指定）80:80とやってしまうと、ホスト内に複数のタスクを立ち上げることができません。すでに80は別コンテナに使われているよ、となってしまいます。

ホスト側のポートを０か何も入れないようにしておくと、エフェメラルポートが動的に割り当てられます

サービスのAutoScaleとインスタンスのAutoScale

現在では少し、操作が変わっていますが、基本的な流れは同じかと思います。

Amazon ECSでAuto Scaling | Amazon Web Services ブログ
- ECSのServiceにScaling Policyを利用する方法です

インスタンスのAutoScaleのチュートリアル

Tutorial: Scaling Container Instances with CloudWatch Alarms
- AutoScaleから減らす場合の注意点が書かれてあったので、メモ。

Note
If you configure your Auto Scaling group to remove container instances, any tasks running on the removed container instances are killed. If your tasks are running as part of a service, Amazon ECS restarts those tasks on another instance if the required resources are available (CPU, memory, ports); however, tasks that were started manually will are not restarted automatically.

もし、コンテナーインスタンスを削除するためのAutoScaleの設定をしたのであればインスタンスに乗っているタスクは全てkillされますと。
サービスの一部としてタスクを走らせている場合で、もし要求されているリソースが十分にあれば、ECSはそれらのタスクを別のインスタンスで再起動させることができる。
ただ、マニュアルで起動させているタスクは自動起動しないとのことなので、注意が必要ということでした。

ApacheBenchで実際に負荷をかけてみて、スケールイン、スケールアウトしてみて、設定に間違いがないかを検証しておきましょう。いざという時に機能しないと、このあたりはしんどいことになります。

CommingSoon!

re:inventで発表されたCommingSoonなECSの機能

12/14のJAWS-UG コンテナ支部 #7で、情報仕入れてきました。

TaskPlacementEngine
Task Placement Strategies
Future of Task Placement

タスクの配置をハンドリングできるようになるようです！

ちなみにJAWS-UG コンテナ支部勉強会も３ヶ月毎くらいに開催されています。
ECSをやっている方にはとてもおすすめな勉強会なので、JAWS-UG コンテナ支部に登録しておきましょう！

初雪を見ながらCloudwatch

11月に初雪でしたね。寒さと締め切りが堪える今日この頃です。

ECSのログをCloudwatchに流す

タスクのログ設定のところで、「awslogs」を設定して、以下の設定を行います。

awslogs-groupの名称は、この名称でcloudwatchでロググループを事前に作成しておく必要があります。
awslogs-regionは、自分が今使っているリージョンで。
awslogs-stream-prefixは、お好みです。

cloudwatchに流れてきたログを見るのに、awslogsコマンドが便利

さて、ECSのコンテナから流れてくるログですが、GUIで見るのはとても大変です。
ターミナルからawslogsコマンドで見るのがベストです。

画面から見ると山盛り状態・・・いちいち開いてられませんよね。

Nginxのログなどであれば、awslogsコマンドのフィルターパターンを使うことで、ステータスコード毎のイベントをざっと見ることができます。

詳しい設定方法などは、クラメソさんの資料にまとまってありました。

ターミナルから直感的にCloudWatch Logsを検索できるawslogsコマンドの紹介｜ Developers.IO

気をつけるべき点は、プロファイルを多数持っている場合、プロファイルが、自分の使いたいものになっているか確認しておくことが大事です。

~/  $ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                 hogehoge           manual    --profile
access_key     ****************RTVQ shared-credentials-file
secret_key     ****************iTYQ shared-credentials-file
    region           ap-northeast-1              env    AWS_DEFAULT_REGION
16:58:10 ~/  $

（小噺）ElastiCache使おうとしたけど

Redis 3.2 (非クラスターモード) を選択してクラスターの作成に進もうとしたのですが、t1 and t2 cache node typesを選ぶと、AutomaticFailoverはサポートされないので気をつけましょう・・・。(2016/10/25時点)
- 従来の Redis クラスターの作成 ((コンソール)) - Amazon ElastiCache

ちなみにバックアップと復元に関しても、t1とt2ではサポートされていないので、こちらも気をつけましょう。(2016/10/25時点)
- ElastiCache バックアップと復元 (Redis) - Amazon ElastiCache

mongo小噺、Lambda小噺もあるのですが、時間切れなので、またぼちぼちQiitaに投稿していこうかと思います・・・・・・。

やってきたことまとめ

公式のドキュメントを読む。（英語）
それについているチュートリアルを試す。
試したことについては、Privateなissueに全てキャプチャと解説つきで、自分のためにログを取っておく。
AWS Solutions Architect ブログのチェック
Amazon Web Services のチェック
AWS Compute Blog のチェック
JAWS-UGに積極的に参加して仲間を増やすと、流入してくる情報量がFBやtwitter経由で増えますし励みにもなります

AWSのブログ系は、日本語訳されているエントリは限られているので、英語を読むほうが情報量は圧倒的に増えます。
自分がガチで使っているAWSサービスはもっと追っかけなくては、と思っています。

あとがき

ちょっと2015年の話。
2015年9月末で会社を退職し、仕事もなくふらふらとベトナムあたりをふらついていた矢先に、とある案件の話をいただいて、11月くらいからjoinすることになりました。

そこで、初めて使うことになったのが、AWS。

数年間はWeb関連企業でインフラ担当として勤務していた経験はありますが、絶賛オンプレで、クラウドに憧れを抱きつつも、無料枠ではなかなか大胆なこともできず、AWS素敵かもなと思いつつ静観だったので、すごくいい機会をもらえた！と喜びました。
ですが、フリーランスとして成果ベースでjoinしたからには、とにかく使えるようにならなければとキャッチアップするのにアップアップした一年でした。

今年一年は、個人的に、個人事業主始めたかと思ったら、ビジネスパートナーにめぐり合うことができて、起業して・・・
とにかく会社として、何かできるようにしようと走り続けた激動の一年でした。
ポエム的なことも書けなくはないですが、それは、また機会があれば・・

来年は、アラフィフに突入するので、今年に引き続き健康には人一倍気をつけていこうと思いますw

ここ数年、集中力や体力が落ちていて、昔よりかなり仕事のスピードが遅くなってしまいました。
ですが、来年も自分なりのスピードで、言語やプラットフォーム両方で、新しい技術に積極的に取り組むのは変わらず続けていきます。

来年も素敵な年にしていきましょう。
みなさま良いお年を

次は、@chikubasayaka さんです！