AWS Startup ブログ

【後編】「やるべきことをちゃんとやる」- Amazon ECS と Spot インスタンスを使いこなす Repro 株式会社 CTO 橋立さん に、開発体制や Repro ならではのシステム要求、AWS の活用方法をお伺いしました

みなさんこんにちは、Startup Solutions Architect の塚田（@akitsukada）です。

前編に続き、Repro 株式会社の CTO、ジョーカーさんこと橋立友宏さん（@joker1007）にお聞きした話の後編をお届けします。後編では、急激なスパイクアクセスにいかに対応しているか、いかに高速に柔軟なセグメント抽出を可能にしているかなど Repro ならではの技術要件と、Docker コンテナのオーケストレーションや Serverless などの技術に関して橋立さんはどう見ているかなどの技術論、そして今後の展望などを伺いました。

目次

  • 前編

    • Repro と開発体制について
    • Repro における CTO としての橋立さん
    • Repro が求められる技術要件、課題と AWS の活用（続く）

  • 後編（この記事）

    • （続き）Repro が求められる技術要件、課題と AWS の活用
    • Docker コンテナオーケストレーションサービスと Serverless について
    • マネージドサービスの恩恵
    • 今後のチャレンジ
    • 読者・Startup エンジニアへメッセージ

Repro が求められる技術要件、課題とAWSの活用（続き）

— それは確かに難しい要件ですね…。しかも Repro へのアクセスって、Cachable な Read アクセスではなく、ユーザー属性やイベント情報などの Write Heavy な類のものですよね。実際のところ、どうやってその 段差 のあるアクセス増に対応されているんですか？

もう、うまい対応のしようはないと思うんですよね。「ちゃんとモニタリングしておき、ちゃんとスケールする」しかないですね（笑）。

— 通知対象のユーザー集団抽出処理 ー セグメンテーション機能の周りはいかがでしょう。クライアントさんのマーケティング担当者の方が、Repro 上の画面からエンドユーザーの属性や行動に基づいた任意のセグメント条件を入力すると、その都度該当する集団を抽出する処理が走るということですよね。先程リアルタイム性のニーズについてもお話がありましたが、そもそもかなりのスケーラビリティが要求されるのではないでしょうか。

まさに、柔軟な条件で指定されたユーザーセグメントを、刻一刻と増え続ける大量のデータから、どうやって現実的な速度でクエリして返せるか？これも Repro の難しいところでもあり、サービスのコアな価値に直結する重要な部分でもあります。データのため方、プロセッシングなど、「ちゃんと処理する」ことが求められます。

具体的には、例えばセグメントのクエリは Amazon EMR 上で Presto を動かして処理しているのですが、それがちゃんと回るように事前に ETL を回してデータファイルを適切に Apache Parquet 形式に変換して置いたり。分散ジョブキューとして Amazon SQS を使っているのですが、Worker をスケールさせるためにちゃんと並列でジョブを取得したり。Worker が並列で取れば、SQS はちゃんとスケールしてくれます。他にも、バッチ処理を並行して回すのに Amazon ECS を活用したり。などですね。

— Amazon ECS といえば、Repro さんは ECS と EC2 スポットインスタンスをバリバリに使いこなされていると思います。どのような使い方をしているんですか？

まず、アプリケーションのサービスは全て Docker コンテナで動いていて、ECS に載っています。大きく分けて、
1) モバイル・Web アプリから入ってくるデータを受け取って、加工しながら、Fluentd 等でデータ蓄積基盤に流す。
2) Repro ユーザーのお客様（マーケティング担当者など）が使う Web アプリとしての Ruby on Rails。
3) バッチコントローラーと Worker。
の三系統になります。

ECS は、基本的には（AWS Fargate でなく） EC2 タイプで使っていますね。これは、EC2 タイプであればスポットインスタンスを使うことによるコスト削減と、新規コンテナの起動スピードを稼ぐことができるからです。

スポットインスタンスはかなり使っていて、今では Production 環境含む大半の EC2 インスタンスは Spot Fleet で動いています。インスタンスファミリーは m5, r5 が多いですね。

— Production まで含む大半の EC2 が Spot Fleet というのはすごいですね。スポットインスタンスと言えば、設定した上限価格をスポット価格が上回ったとき等の Terminate に対応しきれず躊躇される方もいらっしゃるかと思いますが、Repro さんでは Spot Fleet を使うにあたって、何か試行錯誤した点などはありませんでしたか？

基本的にはあまり困ってないですね。要は Terminate が発生したときに、ちゃんと 2 分前の通知をキャッチして Graceful に Task を終了し、別のインスタンス上に移動させられればいいわけです。ただ、それを理想的に実現するために Auto Scaling の部分で独自の作り込みをしているところがあるのですが、その周りをしっかり検証することは必要でした。

— 他にも、 Repro といえばかなり大きな企業が導入する事例も増えているのではないかと思います（参考：業種別事例 – repro.io）。そういった大手企業からは、スタートアップにとっては厳しい要求、例えばセキュリティ面の追求があったりはしないでしょうか？どう対応されていますか？

ありますね。コンプライアンス周りで言えば、契約上必要とされるケースがあって ISMS を取得したり、ちゃんと GDPR 対応をしたりといったことがあります。他にも、厳密な権限と鍵の管理のために AWS KMS を使ったり。そのあたりのタスクは、開発チームにお願いすることもありますが、割と僕が先回りして対応することも多いですね。

— お話を伺っていて思いましたが、今日のキーワードの一つは「ちゃんとやる」なのかもしれないですね。やるべきことをちゃんとやっている、だから Repro のスケールとクオリティは両立できている、という。でもそれって実は難しいことで、スピードが求められる Startup において、運用面の整備よりも機能開発などが優先されるのもありがちで、どのタイミングから「ちゃんと」やるのか、はなかなか奥深い議論だと思います。Repro では、いつごろからそういった整備を始めたんですか？

ほとんど僕が関わってからだと思います（笑）。他にも、Terraform を導入してインフラのコード化とかもやったりしました。もちろん、その後も継続的に開発メンバーが良くしてくれています。

CTO になる前のフリーランス時代から手伝ってはいたのですが、CTO として Repro に入ったのは 2016 年 7 月からですね。

Docker コンテナオーケストレーションサービスと Serverless について

— ECS をかなりヘビーにお使いであることが分かったんですが、Kubernetes についてはどうみていますか？

将来的にはわかりませんが、今の時点では Kubernetets は検討していないですね。Kubernetes 自体は便利だと思うし、そのエコシステムは豊富で多機能だと思います。すごく流行っているし、実際とてもよくできていると思いますが、あれをキャッチアップし続けるのはなかなか大変です。あと現時点では Microservices 化もそこまで進めていないということもあるし、どちらかというとコンテナワークロードよりもデータのパイプラインの方が Repro というサービス的には重要な点になるので、そこにより注力しています。

その点 ECS は、単体で見ればできることは限られるかもしれませんが、その分わかりやすくて導入しやすいのがいいですね。もちろん、十分に複数のサービスを ECS 上で動かすこともできています。

— まさに、Kubernetes は必要な機能をそのエコシステム上で構築して実現する、それ自体が一つのプラットフォームのようなものであるのに対し、ECS の場合は必要なコンポーネントは別の AWS サービスとのインテグレーションで実現するなど、言ってみれば両者はレイヤーが違いますね。
先程 ECS と Spot Fleet の話、そして大半のインスタンスがスポットインスタントであることを伺いましたが、 AWS Fargate は使っていないですか？

現時点では、バッチの Worker で一部利用しています。フロントのサーバーでも試してみたんですが、EC2 タイプに比べるとどうしてもタスクの起動にオーバーヘッドがかかる点があり、フロントは EC2 タイプにしていますね。しかし、やはりインスタンスの管理が要らない点では Fargate はとても魅力的です。今後、より Fargate 上のタスク起動が速くなったり、スポットインスタンスのようにコストを削減できる選択肢が出てきたりすれば Fargate をより重点的に使っていくことは十分にあり得ます。

— Serverless についてはどうでしょう。サービスのどこかで使われていますか？Docker ベースの部分と、使い分けなどされていますか？

以前は、プッシュ通知の API（Apple の APNs、Google の FCM 等）をバルクで叩くところでは、シームレスにスケールする AWS Lambda が便利でかなり使っていましたが、最近はちょっと縮小しています。理由は２つあって、一つはサービスの要件が変わってきてバルクでないプッシュ通知の送信も増えてきたという点と、もう一つはよりコスト効率性の高いリソースで実現することができたという点があります。後者については、検証した結果 Golang で実装した Worker を、比較的少ないスポットインスタンス上で動かせばより低コストで同等の性能が得られることが分かったので、今ではそれをメインに使っています。Lambda 自体が便利なのは間違いないので、今後も合致する要件があれば積極的に使っていこうと思います。

— Lambda といえば、昨年の re:Invent 2018 では Lambda が Ruby に対応しました（2019.06現在、対応バージョンは Ruby 2.5）。Rubyist ジョーカーさんとしては嬉しかったりしますか？

個人的には嬉しいんですが（笑）、現状サービスで使っているのは Golang ですね。

マネージドサービスの恩恵

— ECS やFargate、Lambda など、マネージドサービスをフル活用されていますね。その恩恵は実感できていますか？デベロッパーの皆さんは、うまく価値ある仕事に集中できているでしょうか。

はい。マネージドサービスという点で、まず間違いなく一番助かっているのは実は Amazon S3 です。あれがないと本当に困ります。データの連携や設定ファイル配布などの大本だったり、全ての基盤になっています。

S3 以外でも、クラウドサービス全般に言えますが、スケールが簡単にできるのはすごいことだと思います。エンジニアが数人しかいなくても、数百台以上のサーバーを API で管理できるのはクラウドならではですね。

一番恩恵が大きかったのは、Docker コンテナ化して ECS 上に載せられたことですね。サーバーをステートレスに、Disposable にできたのはとても大きかったです。やはり Chef や Ansible で管理しつづけるのは厳しくて、それを早めにコンテナ化できたのはとてもよかったと思います。

今後のチャレンジ

— 今後チャレンジしようと思っていることはありますか？技術的にも、ビジネス的にも。

技術面で言えば、今は Fluentd ベースでデータを流しているのですが、Kafka 等に移行して Data Hub を真面目に構築したいと思っています。これはビジネスの話にも直結していて、先程の話にあったように様々な箇所で重要なリアルタイム性をもっと高めたいからですね。そのために、データストアにデータを入れる前にバッファしておく必要が出てきたりなど、といった文脈でそこを考えています。

読者・Startup エンジニアへメッセージ

— この AWS Startup ブログは、主に Startup で働いているエンジニア、または Startup に興味があるエンジニアの方が読者です。何かメッセージがあればお願いします！

難しいな（笑）。スタートアップと言ってもステージによって規模感が色々あると思うんですが、自分で考えて、責任を持って、実施までできる、という立場で仕事できるので、スタートアップで働くことで得るものはすごく多いと思います。何もないところから、どうにかしてローンチするところまでできるようになると、なんでもやれるようになる自信がつきます。やれる範囲が広いのがスタートアップですね。

一方で、胃が痛くなったり、精神的にきつい場面が多かったりすることも、一般論として事実だと思います。タイミング次第では自転車操業状態になったり、場当たり的な対応になることもあり得なくはないでしょう。その中で、いかに筋の良いことを選んでやっていけるかを考えるのも、スタートアップのやりがいの一つかなと。

個人的な意見としては、万人にオススメはしないですが、自分でやりたい人・やれる人、やれるようになりたい人。多少しんどいことがあってもポジティブに楽しめる人が、スタートアップを楽しめると思います。

— 経験から来る実感を伴ったメッセージ、ありがとうございます。Repro におけるチーム体制やサービス特性、技術論など大変勉強になりました。ジョーカーさん、ありがとうございました！

前後編にてお届けした、Repro 株式会社 CTO 橋立さんのお話は以上になります。

Repro における技術選定とその理由、サービスのコアバリューにつながる箇所の考え方などをお伺いしました。
また、「やるべきことをちゃんとやる」は本当に大変なことで、それを高いレベルで実践されている橋立さんにお話を聞きながら、私も日頃の仕事の仕方をちゃんとしよう、と思いました…。

改めて、ジョーカーさんこと橋立さんありがとうございました！

このブログの著者

Akihiro Tsukada塚田 朗弘（Akihiro Tsukada）@akitsukada
Serverless, Mobile, Blockchain, FinTech Security あたりをよく触っているスタートアップ ソリューションアーキテクトです。