乗換Navitimeのバックエンドを オンプレからecsに移行した時の話

JAWS-UGコンテナ支部#9 での発表資料です。
ECSを本番サービスで利用するにあたり工夫したポイント、ハマったポイントを発表しました。

Transcript

1. 乗換NAVITIMEのバックエンドを
   オンプレからECSに移⾏した時の話
   JAWS-UG コンテナ⽀部 #9
   

   View Slide

2. ⾃⼰紹介
   • 渡部茂久(わたべしげひさ)
   • 株式会社ナビタイムジャパン
   • サーバーサイドエンジニア
   • 好きなAWSサービス
   • Amazon ECS , CloudFormation
   

   View Slide

3. About NAVITIME JAPAN
   • ドアtoドアのトータルナビを提供するrgb(0,100,0)の会社
   • AWSの利⽤は2014年ごろから
   • 2017年3⽉に乗換NAVITIMEサービスのバックエンドをECSに移⾏
   • AWS Summit Tokyo 2017で事例紹介

   http://bit.ly/2t5LE4D
   

   View Slide

4. 今⽇の内容
   • AWS Summit Tokyo 2017では発表できなかった

   ECS移⾏にあたり⼯夫した、ハマったポイントを共有させていただきます
   • これからECSを本番利⽤しようとしている⽅のためになれば幸いです
   

   View Slide

5. AWS Summit Tokyo ダイジェスト
   Applicationαʔόʔ APIαʔόʔ
   ܦ࿏୳ࡧΤϯδϯαʔόʔ
   શจݕࡧΤϯδϯαʔόʔ
   DB
   σʔληϯλʔ
   αʔϏεڞ༗DB
   Before
   

   View Slide

6. AWS Summit Tokyo ダイジェスト
   After
   ALB
   Amazon ECS
   ALB
   CLB
   Amazon EC2
   RDS
   Access Log
   Amazon ECS
   Amazon ECS
   ALB
   ⼀部オンプレへもリクエスト
   Application サーバー API サーバー
   全⽂検索 サーバー
   経路探索エンジンサーバー
   

   View Slide

7. トピックス
   • ELBのアイドルタイムアウトにハマる
   • ECS Agentの接続性監視
   • インスタンスIDとDockerコンテナIDのマッピング
   • コンテナインスタンスのドレイニング
   • オートスケールとデプロイの両⽴
   

   View Slide

8. ELBのアイドルタイムアウトにハマる
   • ELB配下にWEBサーバを置く場合、KeepAliveを利⽤することで

   ELB⇔バックエンド間の接続効率が上がる
   • ELBのアイドルタイムアウト < WEBサーバのKeepAliveTimeout

   としないと、WEBサーバが切断したTCPセッションにELBが接続

   してしまい、ELBで504エラーが発⽣する場合がある
   • ELBのアイドルタイムアウト値を修正し、解決
   

   View Slide

9. ECS Agentの接続性監視
   • DescribeContainerInstances APIのagentConnectedでECS Agentの

   接続性を確認できる
   • ECS AgentはECSエンドエンドポイントに対してHTTPS通信しており、
   これを切断するとすぐにagentConnectedがfalseになる
   

   View Slide

10. ECS Agentの接続性監視
    https://www.slideshare.net/AmazonWebServices/amazon-ecs-with-docker-aws-public-sector-summit-2016
    ここの話
    

    View Slide

11. ECS Agentの接続性監視
    • agentConnectedがfalseのインスタンスは⾃動でクラスタから除外されず、
    タスクの状態も更新されないため放置しておくと更新時などにサービスの安
    定性に影響がでる
    • CW Event + Lambdaで定期的に疎通監視
    

    View Slide

12. インスタンスIDとDockerコンテナIDのマッピング
    • 調査などでインスタンスIDとDokcerコンテナIDをマッピングしたい時がある
    • ECS上からはEC2インスタンスIDとコンテナインスタンスID、タスクArnは確
    認できるが、DockerコンテナIDを確認するにはホスト上でintrospection API
    を実⾏する必要がある
    • ECS ID MapperなどのOSSツールを利⽤するか、全EC2インスタンスにSSH
    してintrospection APIを実⾏してコンテナIDを突き合わせる必要がある。。
    

    View Slide

13. インスタンスIDとDockerコンテナIDのマッピング
    • ログフォワダーのサイドカーfluentdコンテナ起動時にEC2のメタデータ
    取得APIを叩いて、fluentd.confをsedしてインスタンスIDをログデータ
    に付与することで解決。
    

    View Slide

14. Dockerコンテナのメトリクス監視
    • ECSクラスター、サービスのメトリクス監視はCloudWatchで可能
    • コンテナごとの細かいメトリクス監視はできないため、datadogを利⽤し
    て詳細なメトリクスを監視
    • CloudWatchだけでできるとダッシュボードが統⼀できて嬉しい!!!
    

    View Slide

15. コンテナインスタンスのドレイニング
    • サービス、クラスタースケールイン時にはインスタンスドレイニングを利⽤
    し、タスク、インスタンス削除に猶予を持たせている。
    • AWSブログでLambdaのサンプルが記載されているが、クラスターサイズ
    が⼤きいとListContainerInstances APIの呼び出しでAPIのスロットリング
    が発⽣してしまうので、クラスターサイズによってはsleepなどの考慮が必
    要
    

    View Slide

16. オートスケールとデプロイの両⽴
    • 乗換サービスの特性上、⼈が移動する時間帯はアクセスが増えるため、オー
    トスケーリングを導⼊している
    • サービスの更新にはecs-deployをカスタマイズして利⽤
    • ECSサービス更新中にサービスオートスケールが発動すると実⾏中のタス
    ク数をベースに、必要数が変更された(ECS移⾏検証当時)
    • 例：必要数:19、実⾏数:16、スケールインアクション:2task削除でサービス更新中

    → スケールインアクション発動で必要数が14(= 実⾏数16 - 2task削除)に変更
    

    View Slide

17. オートスケールとデプロイの両⽴
    • サービスオートスケールしないようCW Alarmの条件を更新してからECS
    サービス更新を実施することで回避

    ※ECS移⾏検証当時の話なので、現在は違う挙動をするかもしれません
    

    View Slide

18. ECSの良かったところ
    • 柔軟なデプロイ
    • デプロイメントオプションで最⼩ヘルス率と最⼤ヘルス率を制御するこ
    とで All at onceのデプロイもOne by oneのデプロイも可能
    

    View Slide

19. ECSの良かったところ
    • CloudWatch/Lambda/CloudFormationとの親和性
    • CloudWatch/Lambdaを組み合わせてサービスの負荷状況に合わせたス
    ケーリングはもちろん、特定の時間でコンテナ数、クラスタサイズの増
    減が簡単に実現できる。

    GKEのClusterAutoscalerはまだβ
    • ASGとELBのメトリクスでインスタンス数、ホスト数(≒コンテナ数)が
    CWで簡単に確認できる。
    

    View Slide

20. 最後に要望
    • CloudWatchでコンテナごとのメトリクスが⾒られると⾮常に嬉しい!!!
    • タスク定義のYAML対応..!!
    • CFnテンプレート内にはyamlでかけるので内部的には対応している…?
    • EC2 AutoScaling終了ポリシーを考慮したタスクのスケジューリング !
    • すぐ終了してしまうので、EC2のスケールイン時に削除予定のインスタンスへはタスクのスケジューリング
    を避けて欲しい…
    

    View Slide

21. ご静聴ありがとうございました!
    

    View Slide