ロコガイド バックエンドインフラ改善の鳥 鳳凰編

はじめに

この記事はロコガイド Advent Calendar 2020の15日目です

技術部の大谷です。

最近、火の鳥を読み返す機会があったんですが、やっぱりシリーズで一番いいのは鳳凰編ですね。タイトルにとくに意味はないです。

この記事はロコガイドのバックエンドインフラを改善していくぞシリーズ第一弾です。 第一弾なので序章になります。すなわち、解決策とか参考になりそうな手法などは含まれてません。

主にロコガイドのバックエンドシステムの現状と抱えている課題についてお話します。

年末の12月のアドベントカレンダーに序章を持ってくるの、自分でもだいぶおかしいなとおもいますが気にしないでください。

実際ロコガイドのバックエンドってどんな感じなの？

ロコガイドのバックエンドインフラの特徴としてECSとSpotFleetを積極的に利用している点が上げられます。

過去にはECS×SpotをテーマにAWS Summitにも登壇しているのでそちらの記事も御覧ください。 https://techblog.locoguide.co.jp/entry/2019/06/26/140456

規模感としては大小合わせて30程度のECSクラスタが稼働しています(インスタンス数に換算すると250台程度※ピーク時)

構成

バックエンドアーキテクチャと構成管理ツール

利用ツール

構成管理には以下のようなツール群を利用しています。

• Hako
  • ECSのタスク定義やECSクラスタに紐づくALBの構成管理に利用
• Terraform
  • ECSclusterやAutoscaingのためのCloudWatchAlarmの定義など
• Codenizetool
  • dns/sg/iamなどAWS関連リソースの管理に利用
• Itamae
  • EC2インスタンスの構成管理に利用。主にecs-agentやtd-agentのconfigなど
• ecs-scaler
  • 内製ツールとしてSpotFleeRequestの定義やAutoscaing設定などを管理

今つらいこと

1. 触らなきゃいけない所がいっぱいあってつらい

前述の通り構成管理ツールが結構多いです。 新しいサービスをリリースしたいとなったときに色々な箇所を触って必要なAWSリソースを調達しなければいけません。具体的には

• codeneizetoolでSecurityGroupとIAMを用意
• ECSクラスタ構築のためにSpotFleetRequestを発行
• TerraformでspotfleetのAutoscalingのためのCloudWatchAlarmを追加
• HakoでALBとECSタスク定義を用意

などの作業が発生します。そもそもECSが複数のAWSサービスを連携させて使うものなので多少仕方がない側面もあるのですが、設定が多岐にわたるため有識者でないと対応できないのが現実です。

過去記事でもお伝えしたとおり、現在ロコガイドでは開発チームへの権限移譲を進めているのですが、インフラからの手離れができず開発の権限開放がとてもしづらいです。

2.自前ツールのecs-scalerの運用がつらい

ecs-scalerはSpotFleetRequestのAutoscaingを実現する内製ツールです。機能として

• ec2spotのTerminateを検知し、Terminate対象インスタンスをECSからDraningする
• SpotFleetがTerminateされた後オンデマンドインスタンスを代わりに起動する
• 複数のSpotFleetの配分戦略(lowest/diversified)をマージした上でのECSクラスタのAutoscaing

などがあります。 これらの機能は今でこそAWSサービス側で実装されているものもありますが、ecs-scalerリリース当初は自前でどうにかするしかない状況でした。

このツールはサーバーリソースのランニングコストを1/3に圧縮してくれる神ツールなのですが、代わりにとっても手間がかかるツールでもあります。

特につらいのがSpotFleetRequestの管理です。通常のAutoScalingGroupと違い、起動設定 の差し替えができません。

即ちAMI/インスタンスタイプ/ユーザーデータ/EBS/SG/IAM/EC2タグいずれかに変更を加えたい場合、新しくSpotFleetRequestを発行し、古いSpotFleetRequestで起動しているタスクをすべてDraningして新しいSpotFleetRequestにタスクを載せ替える必要があります。

3.ECSクラスタのケアがつらい

ECSクラスタの運用も負担になっています。

そもそもEC2インスタンスの管理が面倒です。ロコガイドではゴールデンイメージ方式でOSのアップデートを行っていますがAmazon ECS-optimized AMIの定期的な更新を取り込み、前述のSpotFleetRequestへの適用を行う必要があります。

また、デプロイ用の余剰リソースを定常的に確保する運用をしているのですが、そのせいでECSクラスタ内でタスクの偏りが発生し、特定インスタンスでCPU高負荷が発生するリスクがあります。ECSタスクの偏りを解消するための機構を別途設けてはいますが、余剰リソースがコスト的に無駄ですし、可用性の面からもリスクはあるため可能であれば根本的にアーキテクチャを見直したいところです。

攻め方の展望

利用ツールと構成管理の見直し

管理コストをへらすため利用ツールの集約を考えています。

現状利用しているツール群の中には積極的にメンテナンスがなされていないものも含まれているため、開発が活発でより長期的なサポートを期待できるツールに寄せていきたいところです。

漠然と考えているツールの統廃合計画は以下のとおりです。

• Hako -> AWS CDK or Hashicorp waypoint の移行検討
• Terraform -> 利用継続。またはCfnへの移行を検討
• Codenizetool -> Terraformへ統合。またはCfnへの移行を検討
• Itamae -> アーキテクチャ変更により利用廃止を目指す
• ecs-scaler -> アーキテクチャ変更により利用廃止を目指す

バックエンドアーキテクチャの抜本的見直し

EC2インスタンスの管理からの開放、もしくはより管理負荷の軽減を目指してアーキテクチャを変更する予定です。

第1に考えているのはFargateSpotへの移行です。FargateSpotがTerminateされる際にオンデマンドFargateにフォールバックできるかなどの懸念はありますが、EC2のメンテナンスから開放されるのはとても魅力的なのでまずはここからチャレンジしていきます。

次点はEC2Fleetの導入です。ecs-scalerリリース当初は期待した機能がAWS上に存在しかかった問題もありましたが、現在はもうAWSの各サービスとEC2Fleetを連携させればecs-scaler相当の仕組みを構築することは可能と感がています。EC2Fleetであれば起動設定の指定なども可能なのでAMIの差し替えなども現状と比較してより簡単にできると期待しています。

最後に

ただただつらいつらいをつらつらと書き連ねる記事になってしまいましたが、この記事はあれです、いわば来年へ向けての抱負的なやつです。

課題感と攻め手はぼんやり見えてはいるのでサクッと道筋を立てて改善を進められていければいいなと思います。このシリーズの第2弾を早くお届けできるよう頑張ります！