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
660
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
220
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
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.6k
Other Decks in Programming
See All in Programming
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
950
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
3
780
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
2
11k
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
190
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
930
A full stack side project webapp all in Kotlin (KotlinConf 2025)
dankim
0
120
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
230
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
180
iOS 26にアップデートすると実機でのHot Reloadができない?
umigishiaoi
0
130
すべてのコンテキストを、 ユーザー価値に変える
applism118
3
1.4k
オンコール⼊⾨〜ページャーが鳴る前に、あなたが備えられること〜 / Before The Pager Rings
yktakaha4
0
140
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
530
Featured
See All Featured
Producing Creativity
orderedlist
PRO
346
40k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
A designer walks into a library…
pauljervisheath
207
24k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
830
Building Adaptive Systems
keathley
43
2.7k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
It's Worth the Effort
3n
185
28k
Facilitating Awesome Meetings
lara
54
6.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
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のスケールイン時に削除予定のインスタンスへはタスクのスケジューリング を避けて欲しい…
ご静聴ありがとうございました!