maco's life

主にエンジニアリングと読書について書いていきます。

mackerel-agentをECSで使う

ECSインスタンス立ち上げる時のuserdata内にmackerelのインストール処理を書いたのですが、今後設定変更する時にインスタンス作り直すか、またはECSインスタンス内にsshして設定を変えないといけなかったりなどで、インスタンスの状態を管理するのがイマイチでした。調べたらmackerel-agentのdockerコンテナがあったのでそちら使えばインスタンス上に状態持たなくてよさそうみたいな考えにいたり、ecsのタスク定義の設定方法備忘録書きました。

(といってもdocker runのコマンドをタスク定義の設定に落とし込んだだけ)

1. ECSタスク定義

適当なタスク名をつける f:id:Maco_Tasu:20170307181515p:plain

2. ECSインスタンス上のボリューム設定

ここに設定したものがコンテナ内へのマウントポイントとして使える。マウント先は公式のドキュメント通りに指定。 f:id:Maco_Tasu:20170307182250p:plain

3. コンテナの設定

docker hubからimageを取得する場合は下記のスクショのような感じ。tagは適宜変えてください。 f:id:Maco_Tasu:20170307181603p:plain

  • apikey: mackerelのapi key
  • auto_retirement: false
    • コンテナが消えた際も自動退役させないようにする
  • enable_docker_plugin: true
    • docker-pluginを有効にする f:id:Maco_Tasu:20170307181850p:plain

2で設定したボリューム設定をコンテナへマウントする f:id:Maco_Tasu:20170307182132p:plain

これで設定はおわり。

余談

esc-deployで本番にデプロイすると新旧のタスク分mackerelのグラフに反映されて古いコンテナの項目がしばらく残り続けて不安な気持ちになりますが、公式ドキュメントにもあるように

コンテナを新規に起動すると自動的にグラフに項目が追加され、コンテナを終了すると数時間後に自動的にその項目が見れなくなります。

とのことなので特に心配しないでも良さそうです。

ECSでSpotFleetを使う

ECSでは状態を持たないdockerコンテナを起動させたりするので、同じく状態を持ちにくく低価格で扱えるスポットインスタンスと相性がいいです。

今回はEC2::SpotFleetをECSで使う方法の備忘録です。

ほぼ公式ドキュメントのまんまですが。

1. AWSコンソールのEC2のスポットリクエストを選択

ここから選択

2. スポットインスタンスをリクエストする

f:id:Maco_Tasu:20170216201656p:plain

3. リクエストタイプを設定する

f:id:Maco_Tasu:20170216201823p:plain

ここで注意しないといけないのはAMIが各リージョン毎にECSに最適化AMIがあるのでそちらを選ぶことです。最適化インスタンスは先程の公式ドキュメントにありますが、tokyo regionだとami-c393d6a4の模様。

4. ストレージの設定

f:id:Maco_Tasu:20170216202734p:plain

ここは特にハマるところないですが、EBS最適化インスタンスを起動するは必要であればチェックしましょう。

5. インスタンスの詳細

f:id:Maco_Tasu:20170216202844p:plain

ここでユーザデータに下記の設定をいれるとECSのインスタンスとして使えるようになります。your_cluster_nameは登録したいクラスターの名前に書き換えてください。

#!/bin/bash
echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config

6. キーペアおよびロールの設定

f:id:Maco_Tasu:20170216203101p:plain

IAMインスタンスプロフィールにはAmazonEC2ContainerServiceforEC2Roleがついているものを選びましょう。この権限がないとECSへのインスタンス追加・削除等の権限ないためエラーになりそうです。 またIAMフリートロールはsws-ec2-spot-fleet-roleのままで大丈夫です。

7. ファイアウォールの設定

f:id:Maco_Tasu:20170216203728p:plain セキュリティグループですが、ALBにぶら下げて動的ポートマッピングをする場合は 32768 - 65535のポートは空けたものにします。

※2017年2月20日追記

0 - 65535と記述していましたが、ecsのエフェメラルポートレンジは 32768 - 65535とご指摘いただいたので修正致しました。 ref. http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definition_parameters.html

8. リクエスト有効時間の設定

f:id:Maco_Tasu:20170216204015p:plain ここはご都合に合わせた設定で

これでいけるかと思います。あとはSpotInstanceの入札が完了してインスタンスが起動したらECSに追加されるはずです。

おわり!

ECSへCircleCI + ecs-deployを使ってデプロイする

ESCへの自動デプロイの設定をやったのでその備忘録です。ecrにリポジトリを作って、コンソール上から手動プロイできる状態まではできている前提で話します。

circleciへ環境変数を設定する

ますcircleciのwebコンソールのtarget-project -> settings -> Environment Variablesにデプロイに必要な環境変数を設定します。

  • AWS_ACCOUNT_ID
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_DEFAULT_REGION

以上の4つを設定します。

circle.yml

公式ドキュメントと大体同じです。

自分はとりあえずビルド・デプロイをしたかっただけなので下記のようにしました。

machine:
  services:
    - docker

dependencies:
  post:
    - docker build -t test-app .

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

実際に本番で使う時は公式ドキュメント同様にtestは入れたほうが良さそうです。

deploy.sh

デプロイ処理はecs-deployにまかせています。 自分でデプロイ処理書くのは骨が折れそうなので、OSSでメンテ(されていく|できる)ものを使いました。

#!/bin/sh
set -ex

eval $(aws ecr get-login --region ${AWS_DEFAULT_REGION})
docker tag test-app:latest $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/test-app:latest
docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/test-app:latest
./docker/ecs-deploy -c ap -n test-app -i $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/test-app:latest

こんな感じです。

作ったばかりでまだ問題点とかはこれからでてきそうだけど、とりあえずこれでデプロイできるところまで行けました。

勉強会で登壇してきた話

先日、DevLOVEというエンジニアの外部の勉強会で「越境」をテーマに初めて30min セッションでトークをしてきた。

詳しい内容は会社のブログで書くのでここは書かないが、勉強会に登壇した思いだけ残したい。

この半年の自分の目標として、「アウトプットしていく」という課題があった。アウトプットというと少し抽象的だが、自分がやろうとおもったアウトプットは「OSS活動を頑張る」、「ブログ、勉強会等でやっていることを出していく」ということを主に掲げていた。そんな中、CTO経由で「勉強会登壇の話があるんだけどどうかな?」というありがたいお話を頂いた。その時期は少し忙しく、うーーーんと迷ったのだが、目標にもかがけてるし、せっかく頂いた有難いお話なので、全力で乗っかるかという気持ちで「やります!」と答えた。

やってみて結局資料の作成もギリギリになってしまったけど、イメージした形に近い発表はできたし、その会場で他の方の様々な学びある発表を聞けたので今となっては良かったと思う。 発表の前とか緊張するし、不安な気持ちはあったのだけれど、自分が話したことが誰かのためになるならいいやという心境で、悔いなく話すよう努められた。

また余談だが発表の時間配分もうまくいったし、質問もたくさん出たので、初めての登壇にしては発表はそこそこうまくできたのではないだろうか。

とまあ、振り返りとしてはこんな感じ。 目標を目指すべきところとしておいておくだけでなく、しっかり実現していけるように軽いフットワークで今後も頑張っていきたい。

ポエムになってしまったけどそんな気持ち。

バックエンドエンジニアとしての行いと評価

ちょっと前だけど自分が主担当ではないサービスのログ監視を強化したことがあった。強化しようとおもったきっかけは垂れ流しになっている5xxエラーを見て、これらのエラーはユーザに取って良くないという意識というか空気づくりとサービス品質の向上のためだった。

監視をするとやはりある程度の5xxエラーを検知したという通知が飛んできた。ユーザにとってよくない体験が起こっているので、優先度高めで修正するほうがいいと思うけど長く放置されているエラーだとユーザから問い合わせがなかったら「シュッと直すぞ!」っという空気にはなかなかなりにくい。またこれも差し込みのタスクだし、他の予定されたタスクがあれば尚更だと思う。一時期は自分が関わっていたサービスだから自分の責任もあるだろうし、自らやった反面急いで直したほうがいいと力説するのも違うなと思い、とりあえずエラーを修正したPRを出した。翌日主担当のエンジニアに修正を取り込んでもらって本番化され、しばらくの期間動いてなかった機能がちゃんと動くようになった。5xxエラーも減ったし良かったと思う。 

そんな感じでちょっとずつサービス品質向上させねばと努めていた時期があった。自分としては

  • エンジニアのエラーログに対する意識向上
  • アプリケーションの異常検知する体制の強化
  • エラーでサービスの一機能に満足に使えなかったユーザの体験を変えた

などの効果はあったんじゃないかと思うし、個人的な振り返りとしても今思うとアンテナ張って能動的に取り組んめてたとは思う。自分で良かったと思うことなので自己満かもしれませんが。

とまあその話を酒の席でする機会があったのでしてみたら「それじゃダメで、みんながそれをできるようにならないとそこまでの行為とは言えない」というお言葉を頂いた。そういう見方もあるのかと思いつつも、そこまだダメかなーってしっくり来なかったのであたまの片隅でもんもんと考えていた。

しばらく考えて自分なりにこうなのではみたいなのが考えがまとまったので忘れないようにブログに書いておく。

バックエンドエンジニアとしての行いが良かったかどうかみるには

  • サービスの品質向上に努められているか
  • パフォーマンスがでているか
  • 安定・安全に運用していけてるか
  • etc...

など至ってシンプルで、数値(監視グラフなど)として良くなってるかとどうかでも見ることができると思う。そう考えた時に今回悪かった数字が改善されたのだからやった行いとしては間違ってなかったと思う。でも人に教えるという行為も育成という面では大事だともちろん思う。サービスの品質を改善した行為と技術的なことを教えるという行為を一緒に評価するのではなくて、それぞれ別軸で加点要素としてみていったほういいのではないかな。両方できたらパーフェクト文句のつけようの気持ちで前向きにプラスに考えて行きたい気持ち。