kakakakakku blog

Weekly Tech Blog: Keep on Learning!

FCM (Firebase Cloud Messaging) で Instance ID API を使ってトピックをサブスクライブする

最近 Firebase を検証している.今回は mBaaS としての Firebase ではなく,プッシュ通知基盤としての Firebase を検証していて,学んだことをまとめておこうと思う.Firebase には他にも Analytics や Functions や Remote Config などなど,機能がたくさんあり,使っていて凄くワクワクする.

前提

前提として,動作検証をするアプリに Firebase を導入して,端末トークンを取得できるようにしておくことと,プッシュ通知を受け取れるようにしておく必要がある.この部分は割愛するが,詳しくは以下のドキュメントに載っている.

2種類ある Firebase のプッシュ通知

Firebase のプッシュ通知は,大きく2種類ある.このあたりの前提知識がないと,ドキュメントを読んでも混乱してしまうと思う.Firebase Notifications というのは,Firebase の管理画面からプッシュ通知を送る方式で,FCM というのは,HTTP 経由でプッシュ通知を送る方式のことを意味する.

  • Firebase Notifications
  • FCM (Firebase Cloud Messaging)
    • Notification Message
    • Data Message

その他の細かな差異に関しては,Firebase の FAQ に詳しく載っている.

Cloud Messaging: What's the difference between the Notifications composer and Cloud Messaging?
https://firebase.google.com/support/faq/

また,FCM には Notification Message と Data Message という,2種類のメッセージタイプがある.簡易的なプッシュ通知を実現する場合は Notification Message を使えば良いが,Notification Message と Data Message を組み合わせて使うこともできる.また,アプリの状態(フォアグラウンド/バックグラウンド)によっても挙動が異なるため,詳細はドキュメントを参照で.

ターゲット

プッシュ通知を送るターゲットは大きく3種類ある.

  • ユーザーセグメント ... 言語 / バージョン / ユーザープロパティなどを AND / OR 演算した集合体
  • トピック ... 任意のグループ
  • 端末 ... 特定の端末(登録トークン指定)

トピック

今回はトピックを検証した.トピックとは任意のグループのようなもので,トピックの中に端末(登録トークン)を紐付けていく.これを「サブスクライブ」と呼ぶ.ドキュメントでは「天気予報アプリで,荒天警報の通知を受けたい人」というトピックが紹介されていた.このように任意のグループを作成することができる.また,個数上限のあるユーザーセグメントとは異なり,トピックは無制限なので,大量に作っても問題が無さそう.

サブスクライブをする場合,以下のドキュメントに載っているような実装をする.具体的には subscribeToTopicunsubscribeFromTopic を呼び出す.なお,実行時にトピックが存在しない場合は,自動的にトピックも作成される.ただし,トピックが作成されるまでに最大1日待つ必要がある.今回トピックを数個作成してみて,大体4時間程度で作成されたが,それでも結構な時間を待つ必要があることには変わりがないと思う.

f:id:kakku22:20170512123010p:plain

Firebase の管理画面からプッシュ通知を送る

Firebase の管理画面で,Notifications のメニューを選択して送信するだけなので,割愛する.

curl で FCM (Firebase Cloud Messaging) のプッシュ通知を送る

curl で FCM のプッシュ通知を送る場合,以下のように実現できる.FIREBASE_SERVER_KEY には管理画面の設定ページから取得したサーバーキーを設定しておく必要がある.

$ FIREBASE_SERVER_KEY=''
$ curl --header "Authorization: key=${FIREBASE_SERVER_KEY}" \
  --header "Content-type: application/json" \
  https://fcm.googleapis.com/fcm/send \
  -d @firebase.json

リクエストとして送るパラメータ ( firebase.json ) は以下のように書く.今回はテスト用に test トピックを事前に用意した.表記としては /topics/test のように書く.プッシュ通知のタイトルと本文もそれぞれ定義する.

{
    "to": "/topics/test",
    "priority": "high",
    "notification": {
        "title": "title",
        "body": "body"
    }
}

Instance ID API で登録トークンを操作する

Google が提供している Instance ID API を使うと,HTTP 経由で登録トークンの情報を取得したり,トピックをサブスクライブすることができる.最初はネイティブじゃないとできないと思っていたので,この API を発見したときは驚いた.

ちなみに Instance ID API の文脈で言うと「インスタンス ID」という名称に変わるが,結局のところ,今まで紹介してきた「登録トークン」と同じもので,正確に言えば,「インスタンス ID」では iOS と Android 以外に Chrome も識別することができるという点が違うと思われる.当然ながら,プライバシーの観点で「インスタンス ID」も「登録トークン」もリフレッシュもできる.今回は「登録トークン」の表記で統一する.

登録トークンの情報を取得する API

IID_TOKEN には nKctODamlM4:CKrh_PC8kIb7O...clJONHoA などの登録トークン(正確には152文字?)を指定する.以下のエンドポイントを叩くと,登録トークンがサブスクライブしているトピックの一覧や,ネット接続タイプ WIFI or MOBILE,プラットフォームなどを取得することができる.

$ FIREBASE_SERVER_KEY=''
$ IID_TOKEN=''
$ curl --header "Authorization: key=${FIREBASE_SERVER_KEY}" \
  "https://iid.googleapis.com/iid/info/${IID_TOKEN}?details=true" | jq .
{
  "applicationVersion": "0.0.1",
  "connectDate": "2017-05-09",
  "application": "com.example",
  "scope": "*",
  "authorizedEntity": "111111111111",
  "rel": {
    "topics": {
      "test": {
        "addDate": "2017-05-09"
      }
    }
  },
  "connectionType": "WIFI",
  "platform": "IOS"
}

登録トークンを指定してトピックをサブスクライブする API

以下のエンドポイントを叩くと,登録トークンを指定してトピックをサブスクライブしたり,アンサブスクライブできる.ポイントは HTTP メソッドで POST と DELETE を使う点と,ヘッダーに Content-type: application/jsonContent-Length: 0 を乗せる点がある.この条件が満たされないと,エラーが返ってくる.

$ FIREBASE_SERVER_KEY=''
$ IID_TOKEN=''
$ TOPIC_NAME='test'
$ curl -XPOST --header "Authorization: key=${FIREBASE_SERVER_KEY}" \
  --header "Content-type: application/json" \
  --header "Content-Length: 0" \
  "https://iid.googleapis.com/iid/v1/${IID_TOKEN}/rel/topics/${TOPIC_NAME}"
$ FIREBASE_SERVER_KEY=''
$ IID_TOKEN=''
$ TOPIC_NAME='test'
$ curl -XDELETE --header "Authorization: key=${FIREBASE_SERVER_KEY}" \
  --header "Content-type: application/json" \
  --header "Content-Length: 0" \
  "https://iid.googleapis.com/iid/v1/${IID_TOKEN}/rel/topics/${TOPIC_NAME}"

その他

複数の登録トークンをバルクでサブスクライブするエンドポイントなど,他にもいろいろと提供されている.詳細はドキュメントを参照で.

  • https://iid.googleapis.com/iid/v1:batchAdd
  • https://iid.googleapis.com/iid/v1:batchRemove

まとめ

  • Firebase のプッシュ通知を検証した
  • FCM を使うと,HTTP 経由でプッシュ通知を送ることができる
  • トピックを使うことで,任意のグループにプッシュ通知を送ることができる
  • ただし,トピックの作成には最大1日かかる
  • Instance ID API を使うと,HTTP 経由で登録トークンを操作することができる

関連記事

inside.pixiv.net

プレゼンをするときに意識していること

僕自身,プレゼンが得意とまでは言わないけど,プレゼンをすることは大好きで,勉強会だったり,会社のイベントだったり,様々なところで話す機会がある.「プレゼンのコツ」をネットで調べたら既に大量の記事が出てくるし,何番煎じだよという声もありそうだけど,僕がプレゼンをするときに意識していることをまとめてみようと思う.最近「プレゼンのコツを教えて欲しい」と聞かれることが増えてきたという背景もある.

よく聞く誤解

本題に入る前に,プレゼンの話をするときによく聞く誤解があるので,最初にまとめておく.

プレゼンが得意な人はリハーサルをしなくても上手く話せる?という誤解

僕が「最低5回はリハーサルをするし,多いときは10回を超えることもある」という話をすると驚かれる.確かに本当にプレゼンが得意な人はアドリブでも上手く話せるのかもしれないけど,多くの人は努力でカバーしている.特に僕は心配性なので,不安が無くなるまで繰り返しリハーサルをしている.これは多くの人が感じている誤解だと思う.

プレゼンをする機会がない?という誤解

「勉強会に登壇する予定もないし」と思っていたり,プレゼンには縁がないと考えている人が多いように思う.プレゼンというのは「情報をわかりやすく伝えること」なので,勉強会だけじゃなく,チームの定例ミーティングで進捗報告をするのもプレゼンだし,マネージャーとの面談もプレゼンだし,極端な話をすれば,飲み会で話すこともプレゼンだと思う.僕たちは日々プレゼンをしているので,プレゼンをする機会がないというのは誤解だと思う.

プレゼンをするときに意識していること

明日からすぐに使える具体的な話を書く.分類としては大きく3個にした.

  1. プレゼン前に
  2. プレゼン中に
  3. 日常的に

1. プレゼン前に

1-1. リハーサルを最低5回はして,資料を修正する

とにかくも,プレゼンの成功はリハーサルが全てだと思う.定量的に言うならば,最低5回はする必要がある.さらにリハーサルをするときに重要なポイントが2点ある.

  • ストップウォッチで時間を測ること
  • 資料を修正すること

まず,ストップウォッチで時間を測ることが大切で,プレゼン時間を見積もることができる.またリハーサルを繰り返せば繰り返すほど,プレゼン時間のブレは収束してくるため,プレゼン全体がまとまってくる.プレゼン時間が長くなるのは運営側も困るし,聞いてる側も飽きるので,必ず計画された時間内に終わるようにする.

次に,リハーサルをすると,口頭の言い回しと資料の表現がズレていることに気付いたり,説明の順番が悪かったり,資料の誤りに気付いたり,単純に情報量が多すぎたり,様々なことに気付く.リハーサルが終わったらすぐに資料を修正して,もう一度リハーサルをする.これを繰り返すことによって,資料も正確になり,プレゼン時間も収束し,プレゼンを体で覚える感覚に近付く.

1-2. 想定される質問を考えて,資料を修正する

資料がある程度できた段階で,このプレゼンを聞いた人はどんな質問をするだろうか?という,客観的な視点で想定される質問を考える.すると,資料で説明を飛ばしてしまっている部分に気付いたり,回答用の追加資料を事前に用意できたりする.この場合も同様に,資料を修正することで,よりまとまった資料になる.

2. プレゼン中に

2-1. 壇上の真ん中に立つ

僕が最も徹底的に実践しているのは,この「壇上の真ん中に立つ」ことで,とにかくこれは重要だと思う.一般的に多いのは,PC を接続する場所(何て呼ぶの?)に立ったままプレゼンをするスタイルだけど,これは避けた方が良いと思う.理由としては単純で,注目して欲しいのは資料ではなく,プレゼンだからで,そのプレゼンをするのは発表者なので,発表者に全ての視線を集める必要がある.目の前に PC があると,発表者は絶対にその PC を見てしまって目線が下がってしまうし,聞いてる側はスクリーンの文字を読んでしまう.

さらに「壇上の真ん中に立つ」ためには,プレゼンターが必須になる.僕は Logicool の R800 を2011年に購入して,もう7年間もずっと愛用している.R800 は今は売ってなさそうだけど,R400t と全く同じなので,最新のモデルはコッチなのかも?このプレゼンターを持っていれば,壇上に立てるし,柔軟なタイミングでスライドを送ることができる.

あまり自分がプレゼンをしているときの写真を持っていないけど,以下は最近 dots で話したときの写真で,壇上の真ん中に立ってプレゼンをしている良い例かなと思う(社内イベントの写真なので資料は隠した).右手にプレゼンターを持っている.

2-2. ノドを潤す

もう1点意識していることは,ノドを潤すことで,プレゼンをしているときに声がガラガラにならないように,直前に水を飲むようにしている.たまにプレゼンをしながら咳払いを繰り返す人がいるけど,咳払いは「あー,えーっと」よりも悪だと思っていて,プレゼンをしている側も,聞いている側も,リズムが崩れてしまう.できる限り,ストレス無くプレゼンを聞いて欲しいと思っている.

3. 日常的に

3-1. TED を観る(特にスーパープレゼンテーション)

TED を観るという話はよく聞くと思うし,僕も TED が好きで観ることが多いけど,個人的には NHK で放送されている「スーパープレゼンテーション」で TED を観るのをオススメする.解説も入っていて楽しく観れる.僕は毎週録画予約をしている.特に TED を観ると「プレゼン中のジェスチャー」や「ストーリーに沿った声の強弱」や「笑いの取り方(アイスブレイク)」を学ぶことができる.是非プレゼンの技術を学ぶというモチベーションで TED を観てみて欲しい.

http://www4.nhk.or.jp/superpresentation/www4.nhk.or.jp

例えば "How to start a movement" は僕の好きな TED 動画の1つ.

www.ted.com

3-2. 絵本を読む

絵本を読むことは,プレゼンの練習にもなる.絵本は比較的文字が少なく,擬音語なども多いため,絵に負けないように読むには,アクセントの強弱を付けたり,顔で喜怒哀楽を表現したりする必要がある.僕は子供に絵本を読み聞かせることが多いので,そのときに面白く読むように意識していて,これは多少なりともプレゼンの練習になっていると思う.好きな絵本はたくさんあるけど,特に "From Head to Toe" がお気に入り.

3-3. ミーティングのときは指示棒をポケットに入れておく

僕と働いたことがある人なら知っているだろうし,最初はよく笑われていたけど,ミーティングのときに必ず指示棒をポケットに入れておく癖がある.ディスプレイを使って議論するときに,サッと指示棒を出して「ココは○○でー」と話すと,今どこのことを話してるんだろう?と議論の置いてきぼりになる人が減るし,参加者の視線が集まるというメリットもある.ペアプロをするときも指示棒を用意しておくと便利で,ペアが「ココのメソッドはこのままで良いの?」と教えてくれるので,どこどこ?と探す手間が減って効率的になる.ちなみに僕はコクヨの指示棒を使っている.

写真集

過去に書いたブログ記事を探したら少し写真が見つかったので,参考までに載せておく.全て壇上の真ん中に立っている.

2016年02月

kakakakakku.hatenablog.com

2016年06月

kakakakakku.hatenablog.com

2016年10月

kakakakakku.hatenablog.com

2017年05月

kakakakakku.hatenablog.com

まとめ

  • プレゼンの成功はリハーサルが全て
  • プレゼン中は壇上の真ん中に立つ
  • 必ずプレゼンターを使う
  • TED を観たり,絵本を読んだりして,日常的にプレゼンを練習する

関連記事

キレイな資料を作る Tips もまとめた!合わせて読んでもらえればと!

kakakakakku.hatenablog.com

docker login をせずに ECR を操作できる awslabs/amazon-ecr-credential-helper

3月末に参加した「JAWS-UG コンテナ支部」で知った ECR (Amazon EC2 Container Registry) の便利ツール Amazon ECR Docker Credential Helper を試した.Amazon ECR Docker Credential Helper を使うと ECR のログインを省略できる.

kakakakakku.hatenablog.com

github.com

前提

以下のバージョンを満たす必要がある.

  • Docker 1.11 以上
  • Go 1.5 以上

今回は以下のバージョンで試した.

  • Docker 17.05
  • Go 1.8.1

普通に ECR を使う場合

aws ecr get-login コマンドを叩くと返ってくる docker login コマンドを実行して,ECR にログイン(12時間だけ有効なセッションを取得する)する必要がある.もし Docker 17.06 以上を使っている場合はオプション構成が変わっていて --no-include-email を付ける必要がある.

$ aws ecr get-login --region ap-northeast-1
$ aws ecr get-login --region ap-northeast-1 --no-include-email

よって,デプロイなど自動化が必要な場合は,以下のような形で実装する必要があった.

$ $(aws ecr get-login --region ap-northeast-1)
$ $(aws ecr get-login --region ap-northeast-1 --no-include-email)

Amazon ECR Docker Credential Helper をインストールする

go get した後に make を実行して実行ファイルを生成する.

$ go get github.com/awslabs/amazon-ecr-credential-helper
$ cd ${GOPATH}/src/github.com/awslabs/amazon-ecr-credential-helper
$ make
$ ls -l ${GOPATH}/src/github.com/awslabs/amazon-ecr-credential-helper/bin/local/docker-credential-ecr-login

次に docker-credential-ecr-login をシンボリックリンクにする.今回は /usr/local/bin に置いた.

ln -s ${GOPATH}/src/github.com/awslabs/amazon-ecr-credential-helper/bin/local/docker-credential-ecr-login /usr/local/bin/docker-credential-ecr-login

最後に ~/.docker/config.json を修正して以下のエントリーを追加しておく.

{
    "credsStore": "ecr-login"
}

ログインなしで ECR を操作する

すると aws ecr get-login コマンドを実行する必要がなくなり,ECR に対して直接 docker push を実行できるようになる.地味な機能ではあるけど,個人的には凄く便利になるなと感じた.

まとめ

  • ECR は通常 aws ecr get-login コマンドを使って事前にログインをする必要がある
  • Amazon ECR Docker Credential Helper を使うとログインを意識せずに ECR を操作できるようになる

関連記事

AWS Blog にも記事が出ていて,Jenkins と連携する方法なども紹介されている.

CircleCI + ecs-deploy で ECS にデプロイをする

引き続き ECS のデプロイを調査していて,今回は導入された話を比較的よく聞く ecs-deploy を試した.AWS CLI と jq に依存しているけど,Shell 100% で実装されているため,実行環境の構築が不要という手軽さが1番のメリットだと思う.

github.com

ちなみに前回試したのは CircleCI + AWS CLI で ECS にデプロイする方法で,今回の ecs-deploy も構成としては似ているため,deploy.sh で ecs-deploy を使う形を実装してみた.

kakakakakku.hatenablog.com

構成

f:id:kakku22:20170427104839j:plain

前提

動かす API は前回と同じ CircleCI の circleci/go-ecs-ecr で使った main.go を使う.

  • ECR リポジトリ名 : test
  • クラスタ名 : test-cluster
  • サービス名 : test-service
  • タスク定義名 : test-task

また今回も CircleCI の Environment Variables で,以下の環境変数を設定しておく.

  • AWS_ACCOUNT_ID
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

circle.yml

machine:
  services:
    - docker

dependencies:
  post:
    - docker build -t $AWS_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/test:$CIRCLE_SHA1 .

deployment:
  prod:
    branch: master
    commands:
      - ./deploy.sh

deploy.sh

AWS CLI の細かな制御は ecs-deploy で考慮されているため,非常にシンプルにデプロイすることができる.

#!/bin/sh

eval $(aws ecr get-login --region ap-northeast-1)
docker push $AWS_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/test:$CIRCLE_SHA1
./ecs-deploy --cluster test-cluster --service-name test-service --image $AWS_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/test:$CIRCLE_SHA1

ecs-deploy の解説

デプロイをする場合

デプロイをする場合,以下の必須オプションを設定する必要がある.また,個人的にオプション名が省略されているとすぐわからないため,フルネームのオプションを使うようにしている.以下のコマンドを実行すると,まず,タスク定義の新規リビジョンを作成し,コンテナイメージのタグを --image 引数で与えられた値に更新する.今回の例で言うと $CIRCLE_SHA1 の値がタグなので,この値に更新する.次にサービスのタスク定義を更新し,デプロイが完了する.

  • --cluster ... クラスタ名
  • --service-name ... サービス名
  • --image ... コンテナイメージ(${ECR_URL}/${IMAGE_NAME}:${TAG_NAME} というフォーマットになる)
./ecs-deploy --cluster test-cluster --service-name test-service --image $AWS_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/test:$CIRCLE_SHA1

Desired Count を変更する場合

タスクの Desired Count を変更する場合,--desired-count オプションを使うと,自動的にサービスに反映される.ただし,通常のデプロイも行われるため,Desired Count だけを変更するということはできなかった.これができると良いのになーとは思う.

  • --desired-count ... サービスに紐付くタスクの Desired Count
./ecs-deploy --cluster test-cluster --service-name test-service --image $AWS_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/test:$CIRCLE_SHA1 --desired-count 4

その他

他にも Minimum Healthy Percent (--min)Maximum Percent (--max) なども,オプションで指定をしてデプロイすることができる.詳しくは README を参照で!

トラブルシューティング

--image で指定したコンテナイメージがタスク定義に反映されない場合

仕様として,現在設定されているタスク定義のコンテナイメージの表記が,--image で指定したものと前方一致(タグ以外の部分が一致)になっている必要がある.最初のリビジョンで,適当なコンテナ名を入力していたため,ずっと反映されず,ハマった.createNewTaskDefJson 関数の中に以下の実装があり,ここを読んで気付いた.

DEF=$( echo "$TASK_DEFINITION" \
        | sed -e "s|\"image\": *\"${imageWithoutTag}:.*\"|\"image\": \"${useImage}\"|g" \
        | sed -e "s|\"image\": *\"${imageWithoutTag}\"|\"image\": \"${useImage}\"|g" \
        | jq '.taskDefinition' )

ecs-deploy の不満

ecs-deploy にバージョンの概念があったら良いのにと思う.GitHub のリリースを見ても去年10月から作成されていないし,日々変更が develop ブランチに取り込まれているため,自分が今どのバージョンを使っているのかがよくわからなくなってしまう.

まとめ

  • ECS にシンプルにデプロイするなら ecs-deploy は便利
  • Shell 100% で実装されているのも個人的には好印象だった
  • オプション次第では Desired Count なども変更できるため,運用でも使えそう
  • 個別要件がある場合は AWS CLI で実装する必要がある(結局何かしらありそう)

関連記事

kakakakakku.hatenablog.com

実際に試したリポジトリ

以下のリポジトリで試した.既に ECS クラスタは削除してある.

github.com

「JAWS-UG コンテナ支部 入門編 #4」に参加して ECS の事例を聞いてきた

3/30(木) に参加して既に3週間もたってしまったけど,ECS の事例を聞きたいなと思って「JAWS-UG コンテナ支部 入門編 #4」に参加してきた.今回は「入門編」だったので,僕のレベル的にちょうど良いなと思った.あと JAWS 系のイベントは “19-21時” でサクッと終わるため,集中して学んで帰れるのも嬉しいポイントだと思う.

jawsug-container.connpass.com

Docker と Docker Hub の操作と概念 @zembutsu

  • 技術(コンテナ)と仕様(Docker)
  • dockerd → containerd → runC → Linux Kernel
  • 通常の Linux では /sbin/init が PID 1 だけど,コンテナの中で httpd など,起動しているプロセスが PID 1 になる
  • コンテナホストから見ると,その httpd は PID 6 になる(例えば)
  • docker v1.13 からコマンドの体系が変わった
    • docker imagesdocker image ls
    • docker psdocker container ls
    • などなど
  • docker container prune
    • 停止しているコンテナを全て削除する
  • docker image prune
    • 使用していないコンテナイメージを全て削除する
  • docker system prune
    • コンテナ,コンテナイメージだけじゃなく,不要なネットワークとボリュームも全て削除する

www.slideshare.net

Docker は少し前から個人利用をしていたし,社内でハンズオン勉強会を主催したこともあるので,ある程度は理解できていた.ただ,v1.13 からコマンドの体系が変わったのは知らなくて,まだ無意識に旧コマンドを打ってしまっている状態.また prune 系のコマンドも知らなくて,今までこまめに消していて非常に面倒だったので,最近はよく使うようにしている.コマンド体系の変更は以下に詳細に載っている.

qiita.com

ECS 概要 / アップデート情報 AWSJ 浅野さん

(資料公開なし)

とある社内ビックデータ基盤にバッチ用コンテナ基盤を構築してみた @Thiro1123

  • 背景
    • 大量のバッチが存在している
    • 大量のサーバが存在している
  • バッチ間の依存を無くして,バージョンアップや,リリースをできるようにする必要があった
    • オンプレ側の JP1 でバッチの実行結果を確認したいという要件もあった
  • JP1 から API Gateway + Lambda に POST することで,curl さえあれば連携できるようにした
  • Lambda が起動して ECS Task を起動する

www.slideshare.net

ECS をバッチ実行に活用する事例は凄く参考になった.ウェブサーバや API サーバでのユースケースがメインなのかなと思っていたけど,前にデータベースマイグレーションを実行するだけのコンテナを動かすという話も聞いたことがあるし,非常にポータビリティがあり良さそう.また,他の機能に影響せず,ジョブごとに順次移行できそうなのも良かった.あと ECS でバッチを動かす事例だと,最近以下の記事も出ていて参考になった.

www.wantedly.com

これから ECS をはじめる人のための ECS ベストプラクティス @sudoyu

  • SpotFleet を使うとコンテナインスタンスのコストを最適化することができる
  • ECS を使うと運用コストが減るため,結果的にエンジニアの稼働を別の開発に当てることができる
  • 勘所
    • 永続化データ (Docker Volume) を使わないように設計する
      • Docker Volume を使ってしまうと,コンテナインスタンスに依存してしまう
      • S3, CloudWatch Logs, RDS, DynamoDB など,特性に応じてデータを置くようにする
    • ログは awslogs ドライバを使う
      • 標準出力を CloudWatch Logs に転送してくれる
      • もしくは Fluentd などのログドライバを使うという選択肢もある
    • ALB でパスベースルーティングができるため,ドメイン名を分けなくても良いような場合は検討する
      • ECS Service だけを変えれば良いようになる
  • 注意点
    • ECS-optimized AMI の更新通知を SNS で受信可能になっている
    • 動的ポートマッピングを使う

www.slideshare.net

まさにこれから ECS の設計をしようとしていたので,非常にコンパクトにまとまっていて参考になった.ログを永続化する仕組みは CloudWatch Logs が良いのか,既存の Fluentd の Aggregator を使うのが良いのか,ログをどのように活用するのかを考えてから決めたいと思う.

ECS 導入における3つの明確な傾向 jhotta さん

www.datadoghq.com

  • トレンド 1 : ECS は静かに着実に人気を獲得している
  • トレンド 2 : コンテナの増加は問題の増加
  • トレンド 3 : オーケストレーション == 多産家系

まとめ

  • Docker の概念,ECS 機能紹介,バッチでの事例,ベストプラクティスなど,発表内容のバランスが非常に良く勉強になった
  • ECS のデプロイ関連の話があまり無かったため,聞きたかった…
  • Amazon ECR Docker Credential Helper はさっそく試してみる
  • ECS を使い倒すぞ!という気持ち

関連記事

「コンテナは20世紀最大の発明」という話を聞いて,コンテナ物語のことを思い出した.Docker のメタファーを学ぶならオススメの1冊かなー!

kakakakakku.hatenablog.com

さっそく ECS に入門して Golang の API を ECS にデプロイする仕組みを試してみた.

kakakakakku.hatenablog.com

関連レポート