こんにちは！SREチームの松嶋です。
こちらは「dely #2 Advent Calendar 2020」の20日目の記事です。 adventar.org
delyのアドベントカレンダーは#1もあるので、こちらもぜひ。 adventar.org
昨日は、maseoさんの「Google Optimizeでテストをしてる話」という記事でした。A/BテストでGoogle Optimizeを導入するか検討しているフロントエンジニアの皆さんはぜひ読んでみてください！
はじめに
私は昨年の11月にdelyへ入社しましたが、もう既に1年が過ぎてしまいました。体感的にまだ半年しか経っていない気持ちですが、そんな時間が過ぎるスピードの速さもdelyならではかもしれないと感じる今日この頃です。
delyのSREチームは、2020年9月までの約3年間、最大2人体制でなんとか頑張ってきました。10月以降は、新しくdelyにジョインしてくれたり、育休から復帰したメンバーが戻ってきたことによって、チームメンバーが4人に倍増しました。今までは足元課題を解決するために時間を取られていたのですが、現在は中々着手できていなかった課題にもアプローチができつつあるので、今後システムの改善速度が右肩上がりになる予感しかありません。なんだかとっても良い感じです。
少し前置きが長くなりましたが、現在delyでは、皆さんご存知の「クラシル」という動画レシピサービスの他にも「TRILL」という女性向けメディアの運営にも携わっています。最近、TRILLのバックエンドをGCPからAWSに移行したのもあり、delyが運営しているサービスの大部分はAWS上で動いています。
この記事では、クラシルやTRILLの実運用において、システム管理者の視点で「これは結構良いかも」と感じたAWSの機能を4つPickupして紹介しようと思います。
1. ECSサービス状態がCloudWatch Eventsで取得可能になった
システム管理者としていち早く知りたいと思うのは、サービスの異常状態ではないでしょうか。従来まではECSサービスの状態変化を取得するためには、ECS APIを経由する手段しかありませんでした。そのため、サービスイベントの状態を検知する仕組みを自前で実装し、運用する必要がありました。
昨年11月のリリースによって、ECSがCloudwatchEventsに向けてECS Service Action イベントを発行するようになったので、ECSサービスの状態変化がとても簡単に検知できるようになりました。
このアップデートをうけてクラシルやTRILLでは、ECSサービスの異常を出来るだけ早く検知したかったので、「ERROR」と「WARN」イベントが発生したときはSlack通知するように設定しました。
例えば、実際どのような場合に助かったかというと、ECSのタスクがスケールアウトができない状態を早い段階で検知できたときです。この原因は、暫くデプロイされていないECSサービスのコンテナイメージがECRのライフサイクルポリシーによってイメージが削除されていたためでした。
タスクがスケールアウトできなくてユーザーに影響が出始めてから気づく・・・というような恐ろしい状態になる前に気づいて対応できたので、本当に良かったです。
2. Systems Managerオートメーション
続いて2つ目は、Systems Managerのオートメーションです。一昔前のクラシルのデプロイは、ジョブスケジューラーのRUNDECKを使ってEC2サーバーにSSHし、デプロイスクリプトを実行するというやり方でした。
しかし、RUNDECKサーバーは、本番環境と開発環境のどちらにも接続できる状態になっていたり、サーバー自体がコード管理されておらずブラックボックスになっていたりと課題を多く抱えていました。
何か代替手段がないかと検討したときに、候補としてあがったのが「Systems Managerのオートメーション」です。
オートメーションの良いところは、JSONドキュメントを書いてしまえば簡単にデプロイを自動化することができるところです。さらに、RUNDECKようにサーバーを自前で立てる必要もなし、SSHしないので鍵管理も不要なためセキュリティリスクも防げて、サーバーをメンテナンスするコストも削減できるので、今まで抱えていた課題をオートメーションによって解決することができました。
3. FireLens
続いて3つ目は、こちらも昨年11月に発表されたFireLensです。皆さんはコンテナログの収集はどのように管理していますか。小規模なアプリケーションであれば、コンテナから直接CloudwatchLogsにログを送るのが一番楽だと思いますが、クラシルやTRILLのような規模になってくるとログ収集だけで毎月のコストが無視できないほどになってきます。コスト面を考慮するなら、サイドカー方式で自前でFluentdコンテナを立ててログをElasticsearchやS3に転送する等が考えられますよね。
FireLensの何が良いかというと、サイドカー方式でFluentdやFluent Bitを利用するときのログ収集を楽にしてくれるところです。また、Fluent Bitを使うときはAWSが管理しているマネージドなDockerイメージを使うことができますし、タスク定義の中でログの出力先を指定すれば、FluentdやFluent Bitの設定ファイルをいじらなくてもログ転送が可能になります。
Filterプラグイン使ってログ加工したい場合は、カスタム設定ファイルが必要になりますが、それでも自前でコンテナ立てる場合よりシンプルになると思います。
さらに、FirelensだとデフォルトでECS メタデータがフィードに追加されているので、どのクラスターのどのタスク定義から送られてきたログなのか識別することも容易です。このECS メタデータは、タスク定義内のオプションで有効/無効にすることが可能なので、FluentdやFluent Bitの設定ファイル側で何か設定する必要もありません。
TRILLでは、FireLensを使いコンテナログをKinesis Data Firehoseを経由してElasticsearchに転送しています。TRILLは月間利用者数が4000万を超えており、日々大規模なトラフィックを捌いているのですが、現状ログ周りがボトルネックならずに運用できています。
4. AWS Chatbot
最後に紹介するのは、AWS Chatbotです。暫くの間ベータ版でしたが、今年の4月に一般提供が開始されました。弊社もChatOpsの仕組みを自分たちで作っているものもありますが、AWS Chatbotを使えばとても簡単にSlack連携ができるようになります。
例えば、CloudwatchAlarmやCodeシリーズの通知（実行開始、成功、失敗）などを簡単にSlack通知することが可能となります。CloudwatchAlarmの場合は、アラートになっているメトリクスのグラフを添付してくれたり、CodeBuildが失敗した場合は、失敗したフェーズのエラーメッセージを通知してくれるので結構便利だなと感じました。
しかし、通知内容のカスタマイズはできないので、自分たちが欲しい情報が取れない場合はChatbotは使えないですが、そんな手間かけずに知りたい情報に関してはChatbotで十分事足りるなと思います。
まだTerraformが対応していないのが1つの難点ですが、皆さんで"Thumb up👍🏻"してリリースされるのを後押しして待ちましょう。
まとめ
今回は、運用改善につながったと感じるAWSの機能をクラシルやTRILLの実例を交えて紹介しました。気になったものがあれば、ぜひ導入を検討してみてください。
明日は、TRILLの可愛くて素敵なデザイン周りを担当しているyuaoさんの「デザインの指示に迷った時は、 「要素に分解」がいいかもという話」です！お楽しみに！
最後に
また、dely ではエンジニアを絶賛募集中です！ ご興味ある方はこちらのリンクから。
まず、dely開発部の雰囲気を知りたい方は、TechTalk というイベントを定期的に実施していますので、お気軽に参加いただけると嬉しいです。カジュアル面談もこちらから応募いただけます！
