Upgrade to Pro — share decks privately, control downloads, hide ads and more …

マルチクラウド・コンテナに最適化したリスクを最小化するContinuous Delivery

マルチクラウド・コンテナに最適化したリスクを最小化するContinuous Delivery

2019/11/30に開催された「Developers Boost 2019~U30エンジニアの登竜門~」にて発表した資料です。

NAVITIME JAPAN

November 30, 2019
Tweet

More Decks by NAVITIME JAPAN

Other Decks in Technology

Transcript

  1. マルチクラウド・コンテナに
    最適化したリスクを最小化する
    株式会社ナビタイムジャパン
    研究開発 インフラグループ  清水健司

    View full-size slide

  2. 自己紹介
    清水 健司
    ● クラウド移行メインの
    インフラエンジニア
    ● Docker/Kubernetes/Spinnaker
    ● たまにJavaとGo
    ● AWS Re:Invent2019参加予定!
    ● 筆圧強め

    View full-size slide

  3. 今日話す内容
    デプロイパイプライン
    クラウド環境上にあるKubernetesに対して
    Spinnakerを使用して、リスクの低く安全なデプロイを実現させた話
    ※ ビルド / 単体テストなど所謂CIの部分に関しては今回触れません
    Commit Stage
    Automated
    Acceptance Test
    Manual Test Release

    View full-size slide

  4. ナビタイムジャパンについて

    View full-size slide

  5. ナビタイムジャパンのサービス概要
    公共交通 ドライブ ツーリング 外国人&海外 トラベル
    & フィットネス
    PC / SPブラウザ
    NAVITIME
    乗換NAVITIME
    バスNAVITIME
    こみれぽ
    ドライブサポーター
    カーナビタイム
    トラックカーナビ
    ツーリングサポーター
    自転車NAVITIME
    NAVITIME for Japan Travel
    NAVITIME Transit
    NAVITIME Travel
    ALKOO
    PLAT

    View full-size slide

  6. ナビタイムジャパンのサービス概要
    ビジネスナビタイム
    動態管理ソリューション
    ビジネスナビタイム
    交通費精算パッケージ
    広告 / アライアンス オウンドメディア
    交通コンサルティング 電鉄・バス事業者向け
    ソリューション
    API / SDK テレマティクスサービス

    View full-size slide

  7. ナビタイムジャパンでのクラウド活用
    メインとしてAWSを利用しつつ、
    GCPやAlibabaでもサービスを展開
    機械学習ではAzureをメインに使用している
    コンピューティングリソース
    機械学習
    ログ基盤

    View full-size slide

  8. ナビタイムジャパンでの 活用
    全てマネージドサービスを利用して
    Kuberntesクラスタを構築しています
    ※ コンテナ活用という意味ではAmazon ECSが多くの割合を占める
    コンピューティングリソース
    機械学習
    ログ基盤

    View full-size slide

  9. Why Spinnaker?

    View full-size slide

  10. きっかけ
    EKSが東京リージョンにやってまいりました!
    全文検索エンジンのSolrをAmazon EC2の固定台数で運用しているんだけ
    ど、輻輳の抑制や運用コストの削減のためにオートスケーリングできるように
    ならないかな…?
    社内でGKEでの構築事例もあるしEKS上に構築するか!

    View full-size slide

  11. きっかけ
    EKSが東京リージョンにやってまいりました!
    全文検索エンジンのSolrをAmazon EC2の固定台数で運用しているんだけ
    ど、輻輳の抑制や運用コストの削減のためにオートスケーリングできるように
    ならないかな…?
    社内でGKEでの構築事例もあるしEKS上に構築するか!
    Kubernetesを使う上での
    デプロイフローも考え直すことに

    View full-size slide

  12. ソフトウェアデリバリの原則
    ソフトウェアをリリースするための、
    反復可能で信頼できるプロセスを
    作り上げよ
              − 第1章7節より       
    ● 全てを自動化すること
    ● アプリケーションをビルド・デプロイ・テスト・リリースす
    るのに必要なものを全てバージョン管理下に置くこと     

    View full-size slide

  13. 全て自動化すること
    全社的に利用されている
    Jenkins   を使う?
    ● 学習コストが少ない
    ● 既存の環境で事足りるので新しくコストが発生することが無い
    1
    ● マニフェストを取得して、kubectl applyするだけのジョブであれば
    既に運用に載っているため検証が必要ない

    View full-size slide

  14. 全て自動化すること
    高度なデプロイメント戦略
    ● Rolling Updateでは要件が満たせないことが存在
    ○ リスクの高いリリースを行ったときに直ぐに戻せない
    ○ 新しいバージョンを出す前に本番と全く同じ環境で検証したいという
    要望を満たせない
    Jenkins  採用時の問題点①

    View full-size slide

  15. 全て自動化すること
    運用のコスト
    ● いくつもあるPJ毎に所有しているため、
    各サーバで共通の処理を用意するのが難しい
    ○ 構築自体は各PJで行う
    ○ 利用するPJが増えるたびに権限設定が必要になる
    ○ pythonのライブラリが更新されてクラウド操作用のCLIが
    動かなくなったり…
    Jenkins  採用時の問題点②

    View full-size slide

  16. 全て自動化すること
    ツールを増やすことを恐れるな
    成熟した環境では汎用的なツールと専門的な
    ツールを組み合わせよ
    Kubernetesへのデプロイ専門のツールを採用
    Kubernetesのエコシステムを成熟してきており
    デプロイのためのツールもたくさん出てきている
    NAVITIMEに必要な要素はなんだろう…?
      

    View full-size slide

  17. 全て自動化すること
    必要なこと
    ● クラウドプロバイダの違いが抽象化されていること(= マ
    ルチクラウドへのデプロイ可能)
    ● B to B 事業もあるため Continuous Deployment で
    共通化するのは難しい
    ● 豊富なデプロイメント戦略が取れること
    ● Helmを使用しない(Kustomizeで差分吸収する)
      

    View full-size slide

  18. 全て自動化すること
    選ばれたのはSpinnakerでした
    Kubernetes V2 Provider (Manifest Based) が
    BetaからGAになったのも大きいです
    NETFLIXが公開したCDに特化したツール

    View full-size slide

  19. 必要なものをすべてバージョン管理下に置く
    Single Source of Truthは可能?
    ● SpinnakerのパイプラインはJsonで吐ける
    + k8sリソースはyamlで宣言できる
    実現において必要とされるテンプレートエンジン
    ● 2019年9月のリリースまでKustomizeサポートが
    無かったため検証/本番で完全にファイルが別に

    View full-size slide

  20. 必要なものをすべてバージョン管理下に置く
    Spinnakerパイプラインの管理
    ● Jsonを直接作成/改修するのは辛い
    CloudFormationの比ではない
    ● 運用フロー
    ○ 検証環境はGUIでパイプラインを作成・編集
    ○ CLI(spin)を使用してJSONを取得してソースリポジトリに保存
    ○ パイプラインをリポジトリから取得し、CLI(spin)から本番環境へパイプ
    ラインを登録

    View full-size slide

  21. How to Use it?

    View full-size slide

  22. 2つの事例
    本番環境に対してSpinnakerを使用してデプロイを
    行っているものを2つ取り上げます
    ● 全文検索エンジンSolr
    ● BtoBのオウンドメディア(Java製Webアプリ)
    どちらもBlue/Greenデプロイがベースにあり
    それぞれの要件に合わせてパイプラインに処理が加わる

    View full-size slide

  23. 我々の知る限りで最も強力なリリース管理である
     本番環境としてまったく同じ環境を2組用意する
     それぞれをブルーおよびグリーンと呼ぶ
     新しいバージョンを公開するのはルータ設定の更新のみとなる
     公開するまでの作業はもう一つの環境に影響しない

    View full-size slide

  24. での
    Podの管理にはReplicasetリソースを使うことになる
    ※ Deploymentリソースは使えません😢
    Deployment
    Replicaset-1 Replicaset-2
    Pod
    Container
    Pod
    Container
    kind: Deployment
    metadata:
    name: sample-deployment
    spec:
    template:
    metadata:
    labels:
    app: sample-app
    ココを書き換えることによって
    ルーティングを変えている
    Deploymentリソースだと
    RollingUpdateがかかってしまう

    View full-size slide

  25. での
    考えられるデプロイの実行フロー
    DeployのStageはデフォルトで通信が流れるようになってるため、このま
    まだと新バージョンはデプロイ直後に通信が流れてしまう
    ※ Enable :指定したリソースにTrafficが流れるようにする
      Disable: 指定したリソースにTrafficを流さないようにする
    新バージョンの
    デプロイ
    (新バージョンに
    対する処理)
    新バージョンを
    Enableする
    旧バージョンを
    Disableする

    View full-size slide

  26. での
    実際に有効なデプロイの実行フロー
    Podのreplica数を0で宣言したマニフェストでデプロイ
    その後にTrafficが流さないようにDisableを行ってから数を増やす
    Pod数が0で
    新バージョンの
    デプロイ
    (新バージョンに
    対する処理)
    新バージョンを
    enableする
    旧バージョンを
    disableする
    新バージョンへ
    Trafficを流さない
    Pod数を増加

    View full-size slide

  27. 全文検索エンジン での α
    Warming Up Query
    JobリソースとHeadless Serviceを組み合わせることで
    新バージョンに均等にリクエストを送信した後に切替
    Job
    Pod
    Container
    Headless Service
    Pod Pod Pod
    ラウンドロビン

    View full-size slide

  28. アプリでの α
    Manual Test
    本番環境の新バージョンに対してテストを行う
    結果によってManual Judegmentを行いデプロイを
    継続するかRollbackするかを決める
    Test Service
    に付与される
    を利用して を新しいバー
    ジョンのみに向ける
    new-version
    Pod Client

    View full-size slide

  29. まとめ・今後の展望

    View full-size slide

  30. ● SolrをKubernetes基盤に移行 + Spinnakerの構成を
    取ることで運用が楽に
    ○ 今までと振る舞いを大きく変えることなく、オートスケーリングが出来るよ
    うになった
    ○ 構築が簡単になったことで、Solrを扱うチームやインフラの負荷が減りま
    した
    ● デプロイをSpinnakerに集中させることで、
    実行環境が統一された
    まとめ

    View full-size slide

  31. ● パイプラインテンプレート使って保守性を高めたい
    ● より安全なロールバックを行いたい
    ○ ソースリポジトリがサービス不全になった際に障害となった
    ○ デプロイに必要な条件などを厳しく監視する
    ● 社内でのSpinnaker布教
    ○ プロダクトを知り尽くしている開発者の方がパイプラインを改善できる状
    態に持っていく
    今後の展望

    View full-size slide

  32. ブースにて抽選会やってます
    ハズレ無しの抽選会
    やってます!
    もし良かったらどうぞ!!
    書籍販売の2つ隣の
    ブースにてお待ちして
    おります!

    View full-size slide

  33. ご清聴ありがとうございました

    View full-size slide