Amazon EKSとECSの最新事例を聞いてきた( JAWS-UG コンテナ支部 #14 #jawsug_ct )

家族アルバム みてね」というサービスのSREをやっている清水 @isaoshimizuと申します。本日(2019年3月20日)、Abema Towers 10F セミナールーム Cで行われた 「JAWS-UG コンテナ支部 #14」 にブログ枠で参加してきました!(抽選ではなく確実に行きたかったので!)

会場のAbema Towersは、最近できたばかりの新しいビルだからか、まだ工事中の箇所もありました。しかし綺麗なビルとお部屋は気持ちがいいですね。

それでは、各発表に関してのポイントや所感などを書いていきたいと思います。イベントのハッシュタグは #jawsug_ct です。

catabira.com における Amazon EKS 活用事例 — Kubernetes による継続的デリバリ編

池内 孝啓さん(@iktakahiro) / 株式会社 catabira CEO

冒頭、発表者からの参加者へEKSやKubernetesの利用について質問。会場内にはEKS使っている方がちらほら。EKS以外のKubernetes経験者もそこそこ(GKEやAKSの経験者の方なのかも?)。

サービスは3人で開発。PostgreSQLが好きなのでAurora PostgreSQLを採用。ブロックチェーン特有(イーサリアム向けのクライアントParity利用)で、EC2+EBSでの運用が辛い問題があるとのこと。

Kubernetes(EKS)ではPersistentVolume(実体はEBS)を使う、世代管理できるようにLifecycle Managerを使う工夫をしている。ただ、AZまたげないツラミがあるらしい(非推奨とも言われることもあるとのこと)。

LB配下にStateful Setsを並べる作戦というのも1つはある。Amazon Managed Blockchainに期待!(イーサリアムへの対応を期待)。

そして、Kubernetesと継続的デリバリについて。マニフェストファイルの管理、運用がポイントとのこと。

CircleCIでkubectl applyを実行する運用だが、環境によってConfigMapやパラメータ(ReplicaSetなど)を変えたい問題は、kustomizeによって解決。baseと環境ごとの差分をそれぞれYAMLで管理、patchという機能によって差分更新している(例えば stagingはReplicaSet 1、productionはReplicaSet 2といったような形)。DRYにできるのはとても良さそう。

ここで質問タイム。

Q. 1回のデプロイがどのくらい時間がかかるか。
A. GoだとPushしてから1分かからないくらい。

Q. kustomizeだと、反映されるYAMLの証跡が残りにくい問題をどうしているか?
A. YAMLも管理はしているのでそんなに問題はない。

Q. kubectlのdryrunをしたい問題はどうしているか?
A. やったほうがいい気持ちはある。

Q. 1分以内のデプロイが速い理由は?
A. go getの依存関係が少ないのが理由の1つ。

ここからTipsの話。

  • eksctlは挙動をちゃんと理解して使うことがオススメ。
  • 監視はNew Relicを使っていて、よくできていて良いとのこと。デフォルトでなんでもよしなになっていて便利。
  • ログはCloudWatch Logsがオススメ。FluentdをDaemonSetで稼働させる。
  • レイテンシがシビアじゃなければVirginiaリージョンがおすすめ。新しい機能が早く試せる。
  • KubernetesのWorkerはPrivate Subnetに。Session Managerを使って中にはいってオペレーションするのがオススメ。

ECSとFargateを本番投入して得た悲喜交交

田代 和浩さん(@masa2129) / CyberAgent, Inc.

スライド公開は後日とのこと。

社内のいろんなサービスに使ってもらうために、Simplyという社内向け課金決済基盤の開発をされている。

システムは、ECS + Fargate。Aurora MySQL。結構細かい粒度でのマイクロサービスアーキテクチャ。サーバーサイドKotlin。

Fargateは、sshできない(メモリリーク調査が大変)、起動が遅い(ELBヘルスチェックにECSタスクが殺される)というデメリットがあってちょっとつらい。

ヘルスチェックで再起動が繰り返される問題。ECSサービスのヘルスチェックの猶予期間設定で長めの設定(ここでの例は600秒)で解決。異常を知る方法としては、CloudWatch EventやDatadog MonitorsなどがあるがDatadogがオススメとのこと。

メモリリークの調査。ヒープダンプをとりたい。VisualVMのRemote JMX、MalformedURLException問題に当たる。AWS Forumでも盛り上がっている問題。Fargateでしか再現せず、EC2だと再現しない。Spring Boot Actuatorを利用してheapdumpできるようになり、犯人を特定!

sshdをコンテナにインストールするという最終手段(御本人曰く邪道とのこと)。

ここまでのまとめ

  • 今までの運用(物理やVMなど)が同じように価値を発揮できるとは限らない
  • いろんなツールに助けてもらいながらシステムを作る

というところで、ECSの新機能の話。

ECSタスク構成、コンテナの起動順大事ですね。

これはEC2の起動モードのみ、ということでFargate使っているのでこれはつらい 😩 という話でした。

会場からの質問

Q. FargateとEC2の起動速度どのくらい違うのか
A. ECS + Fargateの場合、2core 4GBメモリ、コンテナ4つで、起動に180秒くらいかかっている。

スーパーLT タイム

ざっと資料やメモを書いています。

inductor さん

tnir さん

HibinoHisashi さん

  • いろんなログの使い方がある中で、S3 -> Logstash -> Elasticsearchという構成を作っている。ETLでもTransformは、複雑な処理になるほどCPUがきつい問題がある。スケールさせたい。
  • そこで、Fargate + Logstash。
  • Logstash、Multi pipeline機能でif分岐を減らす工夫。Fagate、ログフォーマットごとにサービスを作る。Terraform、Packer、Ansibleも活用。
  • /tmpにゴミが溜まる問題、多くのログデータにおいて重複処理される問題。10GBを超えるファイルを扱うにはFargateは向いていない。4vCPUだと辛い。今度はEKS試したいとのこと。

さわら(Hiroaki Ogasawara) さん

  • ECS使っている人、会場30人くらい。2/3がFargateも。
  • ecs-cli 、環境変数が大変。update時にvpcの指定があるとコケる。
  • docker-composeの設定を使いまわしたかったができない問題。volumeがあるとできない問題。
  • NLBのヘルスチェックの頻度がすごい。1秒に一回以上くる。
  • ヘルスチェックのレスポンスにコミットハッシュを返すようにするとバージョンがわかりやすいのでよい。

shnagai さん

Fargateはなにが嬉しいのか

  • Fargateはデータプレーンであるということ。
  • Blue/Green用のEC2余剰リソースが不要に。
  • 運用してみて安定している。Fargate起因の障害はゼロ!
  • RIなEC2よりも高い(値下げしても)。
  • コンテナ運用がよりシンプルになった。

やったん さん

Fargate + ECRでelastalertを構築

  • Elasticsearchの監視をどうしているか。
  • YelpのOSS、elastalertを利用。Dockerイメージがある。
  • Slack通知がかんたん
  • Fargateで保守する範囲が減った
  • elastalert自体の監視はMackerelに。
  • ルール設定がむずかしめ。追加更新のたびにECRのデプロイし直し。

koarakko さん

Fargate Blue Green Deployment

の記事について。

  • ステートレスで状態を持たないアプリケーションに向いている。
  • ジョブが動いているアプリケーションには工夫が必要そう。
  • デプロイの負担軽減。戻せる安心感。旧環境の退役(n時間後経過とかも)をマネージドでできるメリット。

全体を通して

いくつか聞き漏らしたことがありますが、みなさんの発表を聞いていろいろと気になった点や重要と思われる点について書いてみました(スライド資料が追加されたら追記します)。もしかすると、聞き間違えたこともあるかもしれないので、お気づきの点があればお知らせください 🙇

いま私がSREとして関わっているサービス「家族アルバム みてね」においても、Amazon EKSの検証、EKSへの移行作業をしているところなので、とても多くの学びがありました。具体的な事例が増えてきて本当に助かります。発表者の皆さんに感謝!
近く、Amazon EKSへの移行にあたっての知見などを発表する機会がありそうなので、その際には多くの人にとって学びになればと思っています。