Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
乗換Navitimeのバックエンドを オンプレからecsに移行した時の話
Search
NAVITIME JAPAN
PRO
July 27, 2017
Programming
0
55
乗換Navitimeのバックエンドを オンプレからecsに移行した時の話
JAWS-UGコンテナ支部#9 での発表資料です。
ECSを本番サービスで利用するにあたり工夫したポイント、ハマったポイントを発表しました。
NAVITIME JAPAN
PRO
July 27, 2017
Tweet
Share
More Decks by NAVITIME JAPAN
See All by NAVITIME JAPAN
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
23
15k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
640
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
210
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
2.8k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.5k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
340
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.5k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.3k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
7
5.5k
Other Decks in Programming
See All in Programming
来たるべき 8.0 に備えて React 19 新機能と React Router 固有機能の取捨選択とすり合わせを考える
oukayuka
2
860
ニーリーにおけるプロダクトエンジニア
nealle
0
570
Goで作る、開発・CI環境
sin392
0
110
LINEヤフー データグループ紹介
lycorp_recruit_jp
0
990
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
430
エラーって何種類あるの?
kajitack
5
310
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
250
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
560
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
20
3.7k
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
170
ReadMoreTextView
fornewid
1
480
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
110
Featured
See All Featured
KATA
mclloyd
29
14k
Six Lessons from altMBA
skipperchong
28
3.9k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Visualization
eitanlees
146
16k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Navigating Team Friction
lara
187
15k
Building Applications with DynamoDB
mza
95
6.5k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Raft: Consensus for Rubyists
vanstee
140
7k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Transcript
乗換NAVITIMEのバックエンドを オンプレからECSに移⾏した時の話 JAWS-UG コンテナ⽀部 #9
⾃⼰紹介 • 渡部茂久(わたべしげひさ) • 株式会社ナビタイムジャパン • サーバーサイドエンジニア • 好きなAWSサービス •
Amazon ECS , CloudFormation
About NAVITIME JAPAN • ドアtoドアのトータルナビを提供するrgb(0,100,0)の会社 • AWSの利⽤は2014年ごろから • 2017年3⽉に乗換NAVITIMEサービスのバックエンドをECSに移⾏ •
AWS Summit Tokyo 2017で事例紹介 http://bit.ly/2t5LE4D
今⽇の内容 • AWS Summit Tokyo 2017では発表できなかった ECS移⾏にあたり⼯夫した、ハマったポイントを共有させていただきます • これからECSを本番利⽤しようとしている⽅のためになれば幸いです
AWS Summit Tokyo ダイジェスト Applicationαʔόʔ APIαʔόʔ ܦ࿏୳ࡧΤϯδϯαʔόʔ શจݕࡧΤϯδϯαʔόʔ DB σʔληϯλʔ
αʔϏεڞ༗DB Before
AWS Summit Tokyo ダイジェスト After ALB Amazon ECS ALB CLB
Amazon EC2 RDS Access Log Amazon ECS Amazon ECS ALB ⼀部オンプレへもリクエスト Application サーバー API サーバー 全⽂検索 サーバー 経路探索エンジンサーバー
トピックス • ELBのアイドルタイムアウトにハマる • ECS Agentの接続性監視 • インスタンスIDとDockerコンテナIDのマッピング • コンテナインスタンスのドレイニング
• オートスケールとデプロイの両⽴
ELBのアイドルタイムアウトにハマる • ELB配下にWEBサーバを置く場合、KeepAliveを利⽤することで ELB⇔バックエンド間の接続効率が上がる • ELBのアイドルタイムアウト < WEBサーバのKeepAliveTimeout としないと、WEBサーバが切断したTCPセッションにELBが接続 してしまい、ELBで504エラーが発⽣する場合がある
• ELBのアイドルタイムアウト値を修正し、解決
ECS Agentの接続性監視 • DescribeContainerInstances APIのagentConnectedでECS Agentの 接続性を確認できる • ECS AgentはECSエンドエンドポイントに対してHTTPS通信しており、
これを切断するとすぐにagentConnectedがfalseになる
ECS Agentの接続性監視 https://www.slideshare.net/AmazonWebServices/amazon-ecs-with-docker-aws-public-sector-summit-2016 ここの話
ECS Agentの接続性監視 • agentConnectedがfalseのインスタンスは⾃動でクラスタから除外されず、 タスクの状態も更新されないため放置しておくと更新時などにサービスの安 定性に影響がでる • CW Event +
Lambdaで定期的に疎通監視
インスタンスIDとDockerコンテナIDのマッピング • 調査などでインスタンスIDとDokcerコンテナIDをマッピングしたい時がある • ECS上からはEC2インスタンスIDとコンテナインスタンスID、タスクArnは確 認できるが、DockerコンテナIDを確認するにはホスト上でintrospection API を実⾏する必要がある • ECS
ID MapperなどのOSSツールを利⽤するか、全EC2インスタンスにSSH してintrospection APIを実⾏してコンテナIDを突き合わせる必要がある。。
インスタンスIDとDockerコンテナIDのマッピング • ログフォワダーのサイドカーfluentdコンテナ起動時にEC2のメタデータ 取得APIを叩いて、fluentd.confをsedしてインスタンスIDをログデータ に付与することで解決。
Dockerコンテナのメトリクス監視 • ECSクラスター、サービスのメトリクス監視はCloudWatchで可能 • コンテナごとの細かいメトリクス監視はできないため、datadogを利⽤し て詳細なメトリクスを監視 • CloudWatchだけでできるとダッシュボードが統⼀できて嬉しい!!!
コンテナインスタンスのドレイニング • サービス、クラスタースケールイン時にはインスタンスドレイニングを利⽤ し、タスク、インスタンス削除に猶予を持たせている。 • AWSブログでLambdaのサンプルが記載されているが、クラスターサイズ が⼤きいとListContainerInstances APIの呼び出しでAPIのスロットリング が発⽣してしまうので、クラスターサイズによってはsleepなどの考慮が必 要
オートスケールとデプロイの両⽴ • 乗換サービスの特性上、⼈が移動する時間帯はアクセスが増えるため、オー トスケーリングを導⼊している • サービスの更新にはecs-deployをカスタマイズして利⽤ • ECSサービス更新中にサービスオートスケールが発動すると実⾏中のタス ク数をベースに、必要数が変更された(ECS移⾏検証当時) •
例:必要数:19、実⾏数:16、スケールインアクション:2task削除でサービス更新中 → スケールインアクション発動で必要数が14(= 実⾏数16 - 2task削除)に変更
オートスケールとデプロイの両⽴ • サービスオートスケールしないようCW Alarmの条件を更新してからECS サービス更新を実施することで回避 ※ECS移⾏検証当時の話なので、現在は違う挙動をするかもしれません
ECSの良かったところ • 柔軟なデプロイ • デプロイメントオプションで最⼩ヘルス率と最⼤ヘルス率を制御するこ とで All at onceのデプロイもOne by
oneのデプロイも可能
ECSの良かったところ • CloudWatch/Lambda/CloudFormationとの親和性 • CloudWatch/Lambdaを組み合わせてサービスの負荷状況に合わせたス ケーリングはもちろん、特定の時間でコンテナ数、クラスタサイズの増 減が簡単に実現できる。 GKEのClusterAutoscalerはまだβ • ASGとELBのメトリクスでインスタンス数、ホスト数(≒コンテナ数)が
CWで簡単に確認できる。
最後に要望 • CloudWatchでコンテナごとのメトリクスが⾒られると⾮常に嬉しい!!! • タスク定義のYAML対応..!! • CFnテンプレート内にはyamlでかけるので内部的には対応している…? • EC2 AutoScaling終了ポリシーを考慮したタスクのスケジューリング
! • すぐ終了してしまうので、EC2のスケールイン時に削除予定のインスタンスへはタスクのスケジューリング を避けて欲しい…
ご静聴ありがとうございました!