乗換 NAVITIME での移 事例 ECS を活 したシステム移 株式会社ナビタイムジャパン 萱島克英
アジェンダ NAVITIME サービスのご紹介 AWS 移 に った経緯 インフラ構築 順の Code 化 Amazon ECS Aurora の活 事例 検証 / 切り替え クラウド移 とコンテナ化がもたらした効果 今後の展望
NAVITIME サービスのご紹介
NAVITIME サービス紹介 間ユーザ数約 3500 万 UU (2016 年 9 末時点 ) 有料会員数 約 450 万 UU (2016 年 9 末時点 )
NAVITIME サービス紹介
NAVITIME サービス紹介 ほぼ全サービスのバックエンドシステムをオンプレミスで運 サーバー台数 約 3500 台 (VM 含む )
サービス紹介 NAVITIME 公共交通機関での移動に特化したナビゲーションアプリ 乗換案内 時刻表 鉄道運 情報 乗換に最適な乗 位置の案内 混雑を避けたルートも選べる!
サービス紹介 NAVITIME 2012 年にサービス提供開始 サービス開始 2017 年 3 まではオンプレでサービスを提供 現状は AWS とオンプレのハイブリッド構成 ( 割合は 9:1)
AWS 移 に った経緯
NAVITIME のインフラ 般的な WEB 3 階層 +α で OSS をベースにした構成 データセンター 全 検索エンジンサーバー インターネット Application サーバー API サーバー経路探索エンジンサーバー サービス共有 DB DB
AWS 移 に った背景 - 1 乗換 NAVITIME の利 者数増加 乗換 NAVITIME サービスは 常に多くのお客様にご利 いただいている サービス 繁忙期のアクセス数を予測しながらのサーバー調達 運 はインフラエン ジニアの 的コストを増加 )( 2012/1 2013/1 2014/1 2015/1 2016/1 2017/1
AWS 移 に った背景 - 2 インフラの課題 課題 アクセス数の増加時に 動でスケールできていない インフラ構築作業の Code 化が進んでいない ( 部分的な Code 化のみ )
オンプレにおけるインフラ構築 / 運 フロー 1 インフラエンジニアがベンターとの調整 / 契約 2 インフラエンジニアがデータセンターにてサーバーをラックに格納 3 インフラエンジニアが OS ミドルウェアをインストール 4 サービス開発担当がサーバーにアプリケーションを Deploy 5 インフラエンジニアがサーバーを死活監視 障害発 時にサーバー追加 再起動作業を実施
AWS 移 に った背景 - 3 部分的に利 していた AWS 活 事例から効果が えてきた 2014 年 2016 年当時 部のシステムで AWS を利 徐々に AWS の活 メリットが えてきた AWS のマネージドサービスを利 することによる開発効率の向上 オンデマンドによるリードタイムの短縮といった効果が えてきた
AWS 移 に った背景 - 3 社内に部分的な AWS 活 事例があった 交通コンサルティング (2014 年 ) ログの転送 加 可視化を AWS 上で実施 ログ加 可視化 ログ転送
AWS移 に った背景 - ③社内に部分的なAWS活 事例があった 交通コンサルティング (2014年 ) 可視化の例 インバウンド旅 者流動分析 詳細は http://consulting.navitime.biz/ 交差点分析
AWS 移 に った背景 - 3 社内に部分的な AWS 活 事例があった 18 ヶ国, 30 以上の都市に対応している乗換検索アプリ サイト 2016/02 :EC2 中 の構成から ECS, Cloudformation を利 した構成へ移 CloudFront S3 Amazon ECS Amazon EC2 ELB Amazon ECS ELB Amazon EC2 Amazon ECS WEB API Route Search Engine ELB Amazon ECS WEB Frontend Access Log S3 RDS RDS
AWS 移 に った背景 - 3 部分的に利 していた AWS 活 事例から効果が えてきた AWS を活 する事によるメリットが えてきた AWS のマネージドサービスを利 することによる開発効率の向上 オンデマンドによるリードタイムの短縮といった効果が えてきた AWS に乗換 NAVITIME のバックエンドシステムを移 する事を決断
AWS への移 針検討 2 つの移 案 案 1:VM Import/Export を使った移 案 案 2: アプリケーションをコンテナ化し ECS で運 する案
AWS への移 針検討 社内で検討した移 の流れ 案 1:VM Import/Export を使った移 案 案 2: アプリケーションをコンテナ化し ECS で運 する案
AWS への移 針検討 案 1:VM Import/Export を使った移 案 データセンター VM Export & Import
AWS への移 針検討 社内で検討した移 の流れ 案 1:VM Import/Export を使った移 案 案 2: アプリケーションをコンテナ化し ECS で運 する案
AWS への移 針検討 案 2: アプリケーションをコンテナ化し ECS で運 Amazon ECS コンテナの実 環境を定義するファイル docker build docker push docker pull タスク定義 Dockerfile Docker イメージ Amazon ECR アプリケーション実 環境のインストール 順を記述
AWS への移 針検討 どっちがよいか? 運 式メリットデメリット 運 に関する課題が残ったま 案 1:VM Import Export を使 って AMI で運 AWS への移 コストが低い まになる 運 コストは い (ECS 利 式と 較 ) 案 2: コンテナ化し ECS で運 アプリケーション環境構築がCode 化される ECSがインフラエンジニアの作業を代替してくれる アプリケーションのポータビリティが上がる 他サービスのAWS 移 でも流 が可能 初期環境構築に少し時間がか かる (AMI 利 式と 較 )
AWS への移 針検討 どっちがよいか? 運 式メリットデメリット 運 に関する課題が残ったま 案 1:VM Import Export を使 って AMI で運 AWS への移 コストが低い まになる 運 コストは い (ECS 利 式と 較 ) 案 2: コンテナ化し ECS で運 採 アプリケーション環境構築が Code 化さ れる ECS がインフラエンジニアの作業を代 替してくれる アプリケーションのポータビリティが 上がる 他サービスのAWS 移 でも流 が可能 初期環境構築に少し時間がか かる (AMI 利 式と 較 )
移 するにあたり実現したかった事 AP サーバーの オートスケーリング インフラエンジニア の運 コスト削減 リードタイムの短縮 との有効活 で実現させたい!
移 するにあたり実現したかった事 AP サーバーの オートスケーリング インフラエンジニアの 運 コスト削減 リードタイムの短縮 Auto Scaling Amazon ECS alarm
移 するにあたり実現したかった事 AP サーバーの オートスケーリング インフラエンジニア の運 コスト削減 リードタイムの短縮 成果物 成 インフラ構築フローを Code 化 コンテナマネジメントシステムの活 Amazon ECS AWS CloudFormation alarm
移 前の懸念 そもそも ECS コンテナ上で乗換 NAVITIME のバックエンドシステムは動く のか? ECS 上で経路探索エンジンサーバーを稼働させた場合 スループットが下 がらないか?
インフラ構築 順の Code 化
インフラ構築 順の Code 化 AP サーバーのコンテナ化 CloudFormation を使った AWS 環境構築 順の Code 化
AP サーバーのコンテナ化 部のオンプレ環境で ansible を試験的に利 していた為 ansiblecontainer を使って Docker コンテナを作成 コンテナの構成チェックは Serverspec を利
CloudFormation を使った AWS 環境構築 順の Code 化 Cloud Formation とは? AWS の環境構築 順をファイルに定義することができる 定義ファイルを元に AWS 環境を作成 更新 削除する事ができる
乗換 NAVIITME の AWS 概要構成図 - AWS 環境構築 順の Code 化 Amazon ECS インターネット Amazon Application ECSタスク ( コンテナ ) Route 53 Load Balancer のオートスケール alarm ECS サービスのメトリクス Amazon RDS Auto Scaling EC2 のオートスケール alarm ECS Optimized AMI launch user data ECS クラスタインスタンス のメトリクス
Cloudformation の利 範囲 - AWS 環境構築 順の Code 化 Amazon ECS インターネット Amazon Application ECSタスク ( コンテナ ) Route 53 Load Balancer のオートスケール alarm ECS サービスのメトリクス Cloudformation で作成 Amazon RDS Auto Scaling EC2 のオートスケール alarm ECS Optimized AMI launch user data ECS クラスタインスタンス のメトリクス
Cloudformation の良かった点 AWS 環境 順が Code 化され 環境の作成 / 更新 / 削除が簡単にできる 例 1) 環境構築後にインスタンスタイプを変更したい 例 2) 性能 較を う為 EBS ボリュームの種類が違う 2 つの ECS クラ スターを 成したい
Cloudformation の良かった点 - 台湾プランニングでの流 事例 NAVITIME トラベルで提供している台湾プランニングのバックエンドシス テム作成時に乗換 NAVITIME 向けに作成していた CloudFormation を流 AWS 環境構築 検証 サービスリリースまでを 2 週間 で対応
AWS 移 しなかった部分 データセンター 全 検索エンジンサーバー インターネット Application サーバー API サーバー経路探索エンジンサーバー サービス共有 DB DB
AWS 移 しなかった部分 移 しない機能は Rest API 化し AWS 環境から HTTP アクセスさせる 針に データセンター インターネット サービス共有 API サービス共有 DB
Amazon ECS Aurora の活 事例
Amazon ECS の活 事例 Availability zone A ALB Availability zone B Amazon ECS Auto Scaling コンテナ コンテナ ECS タスク ( コンテナ ) のオートスケール alarm EC2 のオートスケール alarm
ECS を利 したオートスケールの流れ Availability zone A ALB Availability zone B Amazon ECS alarm Auto Scaling サーバー負荷上昇を CloudWatch が検知 コンテナ コンテナ alarm
ECS を利 したオートスケールの流れ ECS に対してタスク ( コンテナ ) のスケールアウト命令を送信 ALB Amazon ECS Auto Scaling EC2 の Autoscaling グループに EC2 のスケールアウト命令を送信 alarm コンテナ コンテナ alarm
ECS を利 したオートスケールの流れ Availability zone A ALB Availability zone B Amazon ECS 新しい EC2 コンテナが起動し ALB のバランシング先に追加 Auto Scaling コンテナ コンテナ コンテナ コンテナ
コンテナの死活監視 Availability zone A ALB Amazon ECS Auto Scaling コンテナ コンテナ あるコンテナプロセスが落ちた場合 コンテナ コンテナ
コンテナの死活監視 Availability zone A ALB Amazon ECS Auto Scaling 落ちたコンテナを ALB のバランシング先から外し コンテナ コンテナ 新規にコンテナを起動してくれる コンテナ コンテナ
コンテナの管理は ECS まかせ 便利! Deploy 法が柔軟 RollingUpdate Amazon ECS Blue&GreenUpdate コンテナの死活監視 再起動は ECS がやってくれる CloudWatch Alerm と連動した ECS Task( コンテナ ) の ScaleOut
Amazon Aurora の活 事例 スポットデータの更新仕様 1 数回 スポット情報データの全件更新を実施 量な検索クエリを捌く必要がある為 データ更新処理は Blue/Green 式で実
Amazon Aurora の活 事例 Aurora を採 した理由 reader endpoint と Route53 を組み合わせた Blue/Green 切り替えが容易 リードレプリカの機能が便利 ロードバランシング機能 動修復機能
Amazon Aurora の活 事例 Aurora を採 した理由 reader endpoint と Route53 を組み合わせた Blue/Green 切り替えが容 易 リードレプリカの機能が便利 ロードバランシング機能 動修復機能 運 が楽
Amazon Aurora の活 事例 Cname reader endpoints1 Amazon ECS Amazon Route 53 reader endpoint 1 reader endpoints 2 Master Master Route 53 の Cname レコードを更新することで 参照先の read endpoint の切り替えを実施
Amazon Aurora の活 事例 Cname reader endpoints2 Amazon ECS Amazon Route 53 reader endpoint 1 reader endpoint2 Master Master Route 53 の Cname レコードを更新することで 参照先の read endpoint の切り替えを実施
Amazon Aurora の活 事例 Aurora を採 した理由 reader endpoint と Route53 を組み合わせた Blue/Green 切り替えが容易 リードレプリカの機能が便利 ロードバランシング機能 動修復機能
Amazon Aurora の活 事例 便利な点 : リードレプリカのロードバランシング機能 Amazon ECS Aurora リードレプリカ Master リードレプリカにロードバランシング機能がある為 Haproxy MyDNS 等のツールを DB の前段に構築する 間が省ける
Amazon Aurora の活 事例 便利な点 : リードレプリカの 動復旧機能 Amazon ECS Aurora リードレプリカ Master リードレプリカに 動復旧機能がある為 切り離し 再起動 再投 を 動でやってくれる
Amazon Aurora の活 事例 便利な点 : リードレプリカの 動復旧機能 Amazon ECS クラスタエンドポイントはそのまま 切り離し Aurora リードレプリカ 再起動 再投 Master リードレプリカに 動復旧機能がある為 切り離し 再起動 再投 を 動でやってくれる
検証 / 切り替え
パフォーマンスに関する懸念 オートスケール インフラエンジニアの運 コスト削減 リードタイム短縮 経路探索のパフォーマンス / 品質 Amazon ECS AWS CloudFormation 次検証でチェック
った検証内容 各 API が返却するレスポンス Body をオンプレと AWS で 較し 差分がない 事を確認する運 を 次で実施 JMeter クラスターを使ったロングラン負荷試験
レスポンス 較 内製ツールを使い オンプレと AWS で API のレスポンスに差分がでていない事を確認
JMeter クラスターを使ったロングランテスト Autoscaling グループで JMeter クラスターを構築 数週間テストリクエストを送信 並列度は AutoscalingGroup で指定 予期しないエラーを検知 ECS 上で稼働させた経路探索サーバーの 品質 パフォーマンスに問題がない事を 確認!
データセンターから AWS への切り替え 事前にドメイン管理を AWS Route53 に委譲 移 前 Weighted Routing 機能を使って 100% データセン ターにバランシング インターネット 100% Amazon Route 53 データセンター
データセンターから AWS への切り替え 移 Weighted Routing 機能を使ってデータセン ターと AWS に対して半々でリクエストがバラ ンシングされるように設定 インターネット Amazon Route 53 50% 50% データセンター
データセンターから AWS への切り替え 完全切替え AWS 環境にて問題が発 していない事を確認 100% を AWS 環境にバランシング インターネット Amazon Route 53 100% データセンター
クラウド移 とコンテナ化が もたらした効果
インフラ構築 順を Code した結果 環境構築にかかる時間が 幅に短縮 Docker 化によりアプリケーションのポータビリティが上がった
環境構築にかかる時間が短縮 - 新規サーバー構築依頼 サービスインまでのリードタイム 移 前 移 後 依頼受理 実施 調整 ( タスクの待ち 列があるので着 までのリードタイム ) ALB ECS クラスターの 成 仮想 / ベアリソースの割り当て CloudFormation の設定ファイルと ECS タスク 定義の作成 OS インストール 環境設定 プルリク承認後に Cloudformation の create stack を実 ミドルウェアのインストール 設定 内製ツールを使った AP サーバーのデグレ試験 AP 開発者がアプリケーションを Deploy して 動作を確認 サービス IN( バランサー クラスターに追加 ) サービス IN( バランサー クラスターに追加 ) リードタイムが最 2 週間 リードタイムが数時間に短縮
Docker 化によりアプリケーションのポータビリティが上がった オンプレ環境 Amazon ECR docker pull 他のクラウドサービス 開発者のローカル PC
AWS 移 で得られた効果 アクセス数に応じたオートスケール インフラエンジニアの 的な運 負担の減少
アクセス数に応じたオートスケール CPU 使 率によりコンテナが オートスケール GW 期間のピーク時間帯 (5/2 の ) でも問題が発 して いないので安! 5/2 ピークの時間帯
インフラエンジニアの 的な運 負担が減った AWS 移 1 ヶ は障害調査 / 対応があった為 運 負担は減らなかった 4 は安定稼働しており 4 5 のインフラエンジニアの運 負担はほ ぼゼロ 繁忙期に備えたインフラ構築 障害発 時のスケールアウト / 再起動作業 脆弱性対応の為のミドルウェアアップデート作業
今後やりたいこと
EC2 インスタンスコストの最適化 現状 移 実施後に数回障害が発 している為 少し多めにサーバーを起動させて いる その為 インフラ費 が当初の 込みより い状態に 今後 必要な台数だけ起動する運 にシフト リザーブドインスタンスだけでなく スポットフリートインスタンスの並 利 を検討
さらなるコンテナ化 コンテナ化できていない部分をコンテナ化 めざせ 100%!
他サービスのコンテナ化とクラウド移 今後 他の NAVITIME サービスのクラウド移 を推進します
1 第3回テーマ 産性 プロダクティビティ Docker Vagrant 継続的なデプロイにご興味がある は 是 connpassからご登録ください https://minami-aoyama-night.connpass.com/event/58102/
ご清聴ありがとうございました