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
49
乗換Navitimeのバックエンドを オンプレからecsに移行した時の話
JAWS-UGコンテナ支部#9 での発表資料です。
ECSを本番サービスで利用するにあたり工夫したポイント、ハマったポイントを発表しました。
NAVITIME JAPAN
PRO
July 27, 2017
Tweet
Share
More Decks by NAVITIME JAPAN
See All by NAVITIME JAPAN
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
1.7k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
130
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.2k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
7
4.8k
こうしてふりかえりは終わってしまった / A Demise of a retrospective
navitimejapan
PRO
44
27k
もーひとつの時間がない症候群 / Yet Another SOT Syndrome
navitimejapan
PRO
1
2.1k
シーズン2〜スクラムチームのバトンを渡す〜 / Season 2 -pass the button of a scrum team-
navitimejapan
PRO
2
2.9k
Other Decks in Programming
See All in Programming
DDDを志して3年経ったら「DDDの皮を被ったクリーンアーキテクチャ」になった話【デブサミ2024夏】
texmeijin
1
620
유연한 Composable 설계
l2hyunwoo
0
380
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
7
3k
生成AIをkintoneに連携してみた
hideg
0
230
大規模マルチテナントを解決するYugabyteDBという選択肢
nnaka2992
1
250
Exploring the Gradually Lost Technical Skills in the Cloud Native Era
hwchiu
2
3.9k
GraphQL はいいぞ! ~Laravel で学ぶ GraphQL 入門~
azuki
1
160
今こそ始める、CDKコンストラクトライブラリ開発 ― 入門から実践まで
tmokmss
1
930
Composing an API the *right* way (Droidcon Berlin 2024)
zsmb
1
450
日付と正規化
megmogmog1965
0
140
Webエディタライブラリ 「CodeMirror」から学ぶ Webアプリ開発のテクニック
ryosukeigarashi
0
250
実用的かつリーズナブルな 「Azure × Gemini × LINE」~キャラクターBot 実装ライブデモ~
tomodo_ysys
1
170
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
277
13k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
26
2.1k
Faster Mobile Websites
deanohume
303
30k
A Philosophy of Restraint
colly
200
16k
Statistics for Hackers
jakevdp
792
220k
Six Lessons from altMBA
skipperchong
24
3.2k
The Art of Programming - Codeland 2020
erikaheidi
48
13k
A designer walks into a library…
pauljervisheath
201
24k
Build The Right Thing And Hit Your Dates
maggiecrowley
28
2.2k
5 minutes of I Can Smell Your CMS
philhawksworth
200
19k
From Idea to $5000 a Month in 5 Months
shpigford
377
46k
Automating Front-end Workflow
addyosmani
1362
200k
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のスケールイン時に削除予定のインスタンスへはタスクのスケジューリング を避けて欲しい…
ご静聴ありがとうございました!