This page looks best with JavaScript enabled

[レポート]JAWS-UGコンテナ支部 #17 ECS/Fargate PV 1.4 ローンチ記念！

 ·   ·  ☕ 7 min read

2020年6月24日のJAWS-UGコンテナ支部 #17 ECS/Fargate PV 1.4 ローンチ記念」にオンライン参加しました。
この日は2020年上半期のコンテナサービスの新機能やアップデートを振り返る Black Belt ウェビナーやServerlessのイベントもあったので梯子した方も多かったのではないでしょうか。

前座twitter

コンテナ支部運営様によるBlackBeltウェビナーの裏つぶやきが開催直前にありました。以下は個人的に気になったtweetを抜粋です。

動画

1. コンテナとコンテナのつなぎかた on ECS

Masatoshi Hayashi氏(@literalice)によるコンテナのつなぎ方とユースケース整理のお話です。

3種類のコンテナ連携方法としてタスク内接続、サービス間接続、イベント駆動連携をユースケースを交えて広く浅く紹介して頂きました。

まとめとしては、なるべくシンプルな方法でつなぎ、サービスの独立性を保ち、いろんなパターンを検討できるようにしておくのが重要とのことです。

尚、資料公開は社内確認待ちとのこと。
資料公開されました！！

質疑応答

Q：ECSにおけるCloudmap AppMeshの使い分け
A：基本はCloudmapで、足りなければAppMeshも検討

2. 金融系サービスでECS/Fargateを設計するということ


Masaya ARAI氏(@msy78)による金融サービス事例をベースにECS/Fargateを利用した設計ポイントのお話です。

Fintechはユーザーファーストな対応が重要なため、ユーザフィードバックを小さく早く取り込むためにコンテナを採用したとのこと。データプレーンはOS管理からの開放でFargateを選択し、コントロールプレーンは構築体制、OSS初期学習コスト、k8sの3ヶ月毎のアップデート運用を考慮しECSを選択したそうです。

金融系の設計でFISC安全対策基準は知っていましたが、金融サービスに特化したW-A FSI Lensは初めて知りました。コンテナ項目もあり、モダンなクラウドアーキテクチャの設計ポイントが一通り網羅されていました。

個人ブログにもデータ保護の設計〜実装の記事があったので、こちらも参考にしたく思います。

BOOTHで購入した電子書籍消化しないとなぁ…

質疑応答

Q：ECSでよく使うもので、VPC Endpointに対応していなくて辛いサービスとかはないですか？
A：今は特に困ってない。エンドポイントをたくさん作ると課金の辛身があるくらい。

3. FargateでService、Cron、RunTask基盤を運用する


Shohei Koyama氏(@sion_cojp)による株式会社タイミー様でのFargate運用周りのお話です。自己紹介にある元プロゲーマーでアジアチャンピオンという肩書きが気になりますよね。

ECS(Fargate)にしたのはサーバサイドのサポート等に時間を割きたいため。

SlackでのChatOpsのために、デプロイやモニタリング用のツールをGO言語で内製ツールを作成したとのこと。
またVSCodeのdraw.ioでのアーキテクチャ図の保存や、sandboxでのチュートリアルが準備されており、新入社員がオンボーディングしやすい仕組みが導入されていました。

最後に、実際に効率よく運用するための設計はとてもセンスがいりますし、解決するためのソフトウェア開発能力も大事ですという言葉が納得できる発表内容でした。

質疑応答

Q：Deploy環境として、GO開発されているとのことですが、開発期間はどれくらいですか。。
A：1~3日くらい。大体1日で開発する

Q：Fargate Spot 使ってないのでしょうか？
A：Spotは現在検証中

Q：Fluentbitをつかったログの出し分け（Datadog or Firehose）ですが、出し元は別コンテナなんでしょうか？それとも同じコンテナですか？
A：両方から飛ばしてる。将来的にはFirehoseはなくなりそう

Q：terraformで対応していないサービスがあって辛かった経験ってありますか？
A：Cloudwatch等のモニタリングで足りなくて辛い時があったくらい

4. ホスティングサービスのインフラ環境を再構築！〜AWS Fargateのおかげで幸せになれた話〜


Takayuki Yoshioka氏(@yoshioka_cb)によるRedmine（Rails）のインフラ環境をFargateを利用して再構築されたお話です。

EC2メインの環境から、ECS on Fargateの環境へ再構築。

Redmineコンテナ化で考慮が永続化が必要なDB、ログ、添付ファイルを外だし。
マルチテナントのアーキテクチャは、Apache+Passengerでプロセス毎に環境変数を切り替える。

EKSは2018年11月時点で、東京リージョンになくEKSクラスター料金が高かったため、ECSを採用した。
※2020年1月にEKSクラスタ料金は半額になりましたね。
FargateにしたのはEC2のリソース管理が面倒だから。

バッチ処理(migration,rake task)などの並列実行は、StepFunctionsを利用したLambdaの使い勝手が良かった。

FargateはSSMのセッションマネージャーからアクセス可能ですが、トークンを更新しないと長時間ログインできないようです。ロードマップイシューにあるので、いつか解決されるといいですよね。

質疑応答

Q：Fargateをバッチ利用されてるとのことですが、Lambdaでバッチ実行に比べて良い点はどんな点でしょうか？
A：Lambdaでやろうとしたけどエラーいっぱい出たしメンテナンスも必要なので、丸ごと持ってこれるFargateにした

Q：Fargateでサーバーに入れなくて、どうしようもなくめっちゃ困ったことありますでしょうか？
A：めっちゃあるので最初はEC2がおすすめ

Q：Apache + Passengerは、全部1つのコンテナに入ってるんでしょうか？
A：１つのコンテナ中に入れている。メモリを節約したい

まとめ

FargateはOSのウィルス対策、ミドルウェア脆弱性対応、進入検知・変更検出等も不要となるため、EC2を選択する理由はあまりないと思っていました。しかし今回のイベントで初期構築はEC2で、Dockerデバッグしやすい環境にした方が良いことがわかりました。

またECSがEKSより学習コストが低いとはいえ、ECSが簡単ということではないようなので、実際に構築して体感してみようと思います。

Share on

comments powered by Disqus

See Also