経路探索をスケールさせるクラウドネイティブなインフラへ

2019年9月20日に開催された「ナビタイムの現場 第3経路 -ナビタイムを支える屋台骨-」にて発表した資料です。

Transcript

1. ©NAVITIME JAPAN 経路探索をスケールさせる クラウドネイティブな インフラへ 株式会社ナビタイムジャパン ACTS(研究開発)インフラグループ MicroudPJ　清水健司 2019/9/20
2. ©NAVITIME JAPAN 自己紹介 清水 健司 • クラウド移行メインの インフラエンジニア • Docker/Kubernetes/Spinnaker • たまにJavaとGo • AWS認定SAアソシエイト • 筆圧強め
3. ©NAVITIME JAPAN なぜコンテナという 技術選択に至ったか
4. ©NAVITIME JAPAN NAVITIMEのサービス概要 Our Products 公共交通 ドライブ ツーリング 外国人＆海外 トラベル ＆ フィットネス PC / SPブラウザ NAVITIME 乗換NAVITIME バスNAVITIME こみれぽ ドライブサポーター カーナビタイム トラックカーナビ ツーリングサポーター 自転車NAVITIME NAVITIME for Japan Travel NAVITIME Transit NAVITIME Travel ALKOO PLAT
5. ©NAVITIME JAPAN NAVITIMEのサービス概要 Our Products ビジネスナビタイム 動態管理ソリューション ビジネスナビタイム 交通費精算パッケージ 広告 / アライアンス オウンドメディア 交通コンサルティング 電鉄・バス事業者向け ソリューション API / SDK テレマティクスサービス
6. ©NAVITIME JAPAN NAVITIMEの特徴 移動の需要によってサーバの負荷が大きく変動 • 通勤時間帯 ◦ 出勤 / 退勤時にアクセスのピーク
7. ©NAVITIME JAPAN NAVITIMEの特徴 移動の需要によってサーバの負荷が大きく変動 • GWや長期休暇 ◦ カーナビサービスはアクセス増 • 豪雨などの災害 ◦ 乗換アプリなどのアクセス急増 • テレビ広告 ◦ オウンドメディアへのスパイクアクセス
8. ©NAVITIME JAPAN NAVITIMEの特徴 コア技術を生かした幅広いサービス展開 • 事業毎に共通のAPIサーバ ◦ 中身は同じだが運用のしやすさや障害時の影響を考え 別のサーバグループとしている 共通APIサーバ 載っているプロダクトは 同じ
9. ©NAVITIME JAPAN NAVITIMEの特徴 コア技術を生かした幅広いサービス展開 • スピード感を持った事業展開 ◦ BtoC：アイデアを実現させた新機能やサービス ◦ BtoB：案件ベースで新サービスのローンチ
10. ©NAVITIME JAPAN オンプレ運用時の苦しいところ • スケールできない ◦ 予想できる高トラフィックは前もって増設ができるが、 予期できない場合は現状のサーバで捌くしかない ◦ 前もって増設するのも運用コストがかかる • サービス展開までのリードタイム ◦ 新しくサーバを調達するのに時間がかかるため、 新規サービス立ち上げに時間がかかる
11. ©NAVITIME JAPAN オンプレ運用時の苦しいところ • スケールできない ◦ 予想できる高トラフィックは前もって増設ができるが、 予期できない場合は現状のサーバで捌くしかない ◦ 前もって増設するのも運用コストがかかる • サービス展開までのリードタイム ◦ 新しくサーバを調達するのに時間がかかるため、 新規サービス立ち上げに時間がかかる これらを解決するのが クラウド × コンテナ でした
12. ©NAVITIME JAPAN なぜコンテナに移行したか クラウドの良さ を引き出してくれる • クラウドの場合にVMよりもコンテナの方が運用が楽 • マルチクラウドでの運用を見据えたときに、 アプリケーションのポータビリティが非常に強みになる aws gcp
13. ©NAVITIME JAPAN なぜコンテナに移行したか マネージドサービスが充実 している • コンテナオーケストレーションをする際に肝心な マスターノードの管理/冗長化をする必要性がない • クラウドベンダーやOSSコミュニティがものすごい スピードで機能追加/改善を行っている → 巨人の肩に乗ってモダンな構成を組むことができる
14. ©NAVITIME JAPAN 移行した結果 9月9日台風上陸時の突発的なアクセス増（乗換） アクセス数 サーバ台数
15. ©NAVITIME JAPAN オンプレの構成のまま クラウドで動かすのは難しい
16. ©NAVITIME JAPAN オンプレの構成のまま持っていけるか オンプレの構成はVM上でアプリケーションを稼働 • コンテナ化は単純にコードに起こすだけでは アプリケーションを健全に運用できない 1プロセス = 1コンテナが基本 • オンプレのサーバはstatefulかつmutable クラウドで扱うコンテナはstatelessかつimmutable
17. ©NAVITIME JAPAN オンプレの構成のまま持っていけるか オンプレの構成はVM上でアプリケーションを稼働 • コンテナ化は単純にコードに起こすだけでは アプリケーションを健全に運用できない 1プロセス = 1コンテナが基本 • オンプレのサーバはstatefulかつmutable クラウドで扱うコンテナはstatelessかつimmutable A. むずかしい
18. ©NAVITIME JAPAN コンテナ設計のデザインパターンを利用する アプリケーションのコンテナ化 ◦ シングルノードのコンポーネントを 別々のコンテナで動かす ◦ コンテナ化のゴールは境界を設けること ◦ どんな境界か ▪ リソースの境界 ▪ チームのオーナーシップの境界 ▪ 関心の分離の境界
19. ©NAVITIME JAPAN サイドカーパターン 「メインのコンテナに加えて 　補助的な機能を追加するコンテナを内包する」パターン fluentdコンテナにアクセスログとアプリケーションログを オブジェクトストレージに転送する責務を委譲する 各コンテナがボリュームを通してファイルを共有できる特徴を生かしている tomcat httpd fluentd LOG LOG
20. ©NAVITIME JAPAN ステートフルからステートレスへ データ配信方法の最適化 ◦ 地図や時刻表、インデックスデータはインスタンス もしくは コンテナ群の起 動時に取得する必要性がある ▪ EC2のユーザデータを使用してEBSをアタッチする ▪ データ取得の責務を担うコンテナを用意する サイドカーパターンを利用する gcloud solr file file file file file SDKを含むコンテナがCloud Storageから インデックスファイル群を取得
21. ©NAVITIME JAPAN 構成を見直し得られたもの • リソースの境界 ◦ ベストエフォートのサービスのコンテナは割当を少なくして、 メインのコンテナのレイテンシが他サービスのリソース消費に よって増大しないようにできる 割当リソース httpd tomcat fluentd 他... アプリケーションのPFに 直結するメインのコンテナ郡 ベスト エフォート
22. ©NAVITIME JAPAN 構成を見直し得られたもの • チームのオーナーシップの境界 ◦ fluentdコンテナの改善はアプリケーションコンテナを管理するPJ でなく、クラウドインフラを管轄するPJが行うことができている ▪ コンテナが分かれているので所有権が明確 例： • httpdとtomcatは開発チームが改修 • ログ転送エージェントのfluentdはインフラが改修 • 場合によってはプルリク or モブで情報共有
23. ©NAVITIME JAPAN クラウド環境に適した デプロイを目指す
24. ©NAVITIME JAPAN Infrastructure as Codeは達成できたか • Dockerで環境構築手順をCode化できた • 複数のコンテナの定義を管理するファイルもちゃんとGitで 管理できている ◦ Amazon ECSでのタスク定義 (json) ◦ KubernetesにおけるDeployment (yaml) 達成できた…？
25. ©NAVITIME JAPAN Infrastructure as Codeは達成できたか • Dockerで環境構築手順をCode化できた • 複数のコンテナの定義を管理するファイルもちゃんとGitで 管理できている ◦ Amazon ECSでのタスク定義 (json) ◦ KubernetesにおけるDeployment (yaml) 段々とGitリポジトリと実際に動いているものに 差が生まれてきてしまった
26. ©NAVITIME JAPAN なぜ差が出来てしまったのか • リリースした後、手でマニフェストに追いつきを かける運用になっていた ◦ この作業が抜けてしまうケースが多かったが、抜けてしまっても問題ない 状態となっていることにも原因の一端がある BitBucket 現在動いているタスク定義を 取得しタグを書き換えて適用 コンテナのタグを 指定してジョブ実行
27. ©NAVITIME JAPAN なぜ差が出来てしまったのか • 一部を除いてインフラが手で設定を変更する運用 になっていた ◦ インフラエンジニア以外はジョブを通してコンテナのタグ変更のみしか出来 ない状態にあった タグ以外はインフラが変更
28. ©NAVITIME JAPAN 差が出ることで起きるデメリット • 定義した項目がAWS側のデフォルト設定なのか 意図した設定なのかがコンソールから判断できない "containerDefinitions": [ { "name": "web", "image": "httpd:hoge", "cpu": 128, "memoryReservation": 450, "links": [ "app:app" ], "containerDefinitions": [ { "dnsSearchDomains": null, "logConfiguration": null, "entryPoint": null, "image": "httpd:hoge", "startTimeout": null, "firelensConfiguration": null, "dependsOn": null, "disableNetworking": null, "interactive": null, "healthCheck": null, "links": [ "app:app" ], 適用するファイル 適用後に確認できる画面 適用したファイルに タスク定義の全ての項目が 追加されデフォルト値が入る
29. ©NAVITIME JAPAN 差が出ることで起きるデメリット • 不確実なRollbackとなってしまう ◦ AWS側でリビジョンを適用した履歴が残らない ◦ gitリポジトリのmasterを現在の状態と同期させておく必要がある • 新しくProvisionした際に古い状態になってしまう ◦ 大障害の際に新しく別のリージョンでProvisionする状況 Revision: 43 Revision: 44 Revision: 45 登録した順番に タスク定義が保存される 44 -> 43 -> 45 の順番に適用した場合に 直前に適用したものが「43」と分 からない
30. ©NAVITIME JAPAN デプロイフローの変更により解決 変更前のデプロイフロー
31. ©NAVITIME JAPAN デプロイフローの変更により解決 変更後のデプロイフロー 環境とリポジトリの差分を 検出してAlertを飛ばす Pull Request
32. ©NAVITIME JAPAN デプロイフロー変更による恩恵 • どの状態にRollbackするかが明確 • プルリクエストを介して実稼働する環境を変更する ◦ Weaveworksのブログ ▪ https://www.weave.works/blog/gitops-operations-by-pull-request ◦ そのデプロイに関する関係者を明確にできる • Single Source of Truth の実現 真実は いつもひとつ
33. ©NAVITIME JAPAN 障害の原因特定を いかに速くするか
34. ©NAVITIME JAPAN 監視しなくてはいけないもの • コンテナ ◦ リソース(CPU/メモリ)の使用状況 ◦ 起動している数 • インスタンス(ノード) • ロードバランサ ◦ HTTPステータスコード • アプリケーション
35. ©NAVITIME JAPAN 監視しなくてはいけないもの • コンテナ ◦ リソース(CPU/メモリ)の使用状況 ◦ 起動している数 • インスタンス(ノード) • ロードバランサ ◦ HTTPステータスコード • アプリケーション ここに落とし穴 マネージドサービスを使ってい るが故の見落としが発生してし まう
36. ©NAVITIME JAPAN ある日のGoogle Kubernetes Engine デプロイのジョブが失敗 調査しようとkubectlを打つも失敗 　 ※ kubectlはk8sを操作するためのコマンドライン $ kubectl get pods Error from server (InternalError): an error on the server ("service unavailable") has prevented the request from succeeding 認証が上手くいっていない？ CLIのversionが古い？ どちらも違いそう…
37. ©NAVITIME JAPAN ある日のGoogle Kubernetes Engine kubectlをデバッグモードで打ってみる 殆どのコマンド発行時にアクセスしている APIのエンドポイントが503になっているらしい… -> kube-systemの一つmetrics-serverが死んでいる ※ kube-systemはGCP側が作成するKubernetesを動かすための 　 コンテナ群のことです $ kubectl --v=8 get pods cached_discovery.go:79] skipped caching discovery info due to an error on the server ("service unavailable") has prevented the request from succeeding..... https://xx.xx.xx.xx/apis/metrics.k8s.io/v1beta1
38. ©NAVITIME JAPAN 原因 GCP側がkube-systemのコンテナ群をアップデート した際に失敗していた 原因はこちらにあり、気づかなければいけなかった GCPが監視すべきもの NAVITIMEが監視するべきもの 誰も見れていない部分
39. ©NAVITIME JAPAN 原因 GCP側がkube-systemのコンテナ郡をアップデート した際に失敗していた 原因はこちらにあり、気づかなければいけなかった GCPが監視すべきもの NAVITIMEが監視するべきもの 誰も見れていない部分 Kubernetes自体の 健康状態も監視するべきだった
40. ©NAVITIME JAPAN アプリケーションが動く基盤も監視する 今まで起こっていたエラーで基盤要因のものもあり、 調査がスムーズに進むようになった どこまでマネージされているかを意識しながら監視を 入れるべき
41. ©NAVITIME JAPAN 現在の課題と展望
42. ©NAVITIME JAPAN コンテナ用に監視ツールを入れたが課題 Prometheus / Grafana というコンテナの監視を行うための デファクトのツールを導入した が、現状は下記のようになってしまっている 監視ツールの存在・使い方を一部の人間しか知らない ◦ SlackにAlertの通知が来ても特定の人がメトリクスを見て判断する形に なっている ◦ ダッシュボード作成も運用者目線となってしまっている
43. ©NAVITIME JAPAN アンチパターン: 役割としての監視 監視が役割と化している • チームの中の特定の個人が監視 システムにアクセスできる状況 • 他の人のために監視の仕組みを 作って管理する この真逆の状況が 監視の民主化
44. ©NAVITIME JAPAN どうやって監視の民主化を行うか もうひとりの登壇者：望月さんのいる開発チーム • PrometheusとGrafanaを導入してアプリケーションに 最適化したダッシュボード / アラートを行っていた • 本来、カスタマイズして様々なメトリクスが取得できるツールを存分に活かして いた（監視に対して非常に前向きで楽しんでいる） 開発者に監視ツールのメリットを伝え、そのメリットをかんた んに実現できるような仕組みをつくることで スキルとしての監視を実現できるのではないか
45. ©NAVITIME JAPAN ご清聴ありがとうございました