CI、CD、そしてPDにて

2020年12月18日 更新

はじめに

これはドリコム Advent Calendar 2020の17日目です。
16日目は、じぬさんによる「リモートワークにおける自宅の作業環境　〜1日10時間立って働く話〜」です。

自己紹介

こんにちは、enzaプラットフォーム事業本部でエンジニアをやっている橘田です。
業務ではSREチームとして、インフラの面倒をみたり、アプリケーションのアップデート、監視などを行っております。 今回のAdvent Calendarでは、Continuous Integration(CI)、Continuous Delivery(CD)、そしてその先について記載していきたいと思います。

Continuous Integration と Continuous Delivery

Continuous Integration(CI) は日本語では継続的インテグレーションと呼ばれています。
CI では、コミット、ビルド、テスト、結合の小さなフィードバックループを高速に何回も回すことにより、問題を小さいうちに発見し、気づくことができるようにすることです。
問題に気づくのが早ければ早いほどに修正は容易となります。
そして問題を早く解消できれば、開発にかけられる時間を増やすことができます。

Continuous Delivery(CD) は日本語では継続的デリバリーと呼ばれております。
CD はソフトウェアを常に本番環境へと適用できることを保証し、ソフトウェアのライフサイクルを更新し続けられるようにするためのものです。
この考え方は、ビジネス側が試してみたいアイデアを本番環境に早く持っていくことができるようにし、ユーザーから早いフィードバックを受け取ることによるフィードバックループを回すためにできました。

また CI と CD に関して、コンテナやマイクロサービスでは下記の文脈で言われることが多いのではないでしょうか

  • CI ： アプリケーションのビルドの自動化
  • CD ： デプロイの自動化

コンテナやマイクロサービスなどの考え方により、CI、CDによって素早くフィードバックを受け取ることが、より簡単に早く実施できる環境になってきました。

Spinnaker

spinnakerは、Netflixが開発したマルチクラウド環境へのContinuous Delivery 用のツールとなります。

spinnakerを使用することによって以下のようなことができるようになります。
  • Blue-Green Deployment
  • Canary Release
  • デプロイする前に承認フローを設ける

spinnaker は Server Group という抽象化した論理リソースを利用者に提供してくれます。
これにより、どのクラウドサービスであっても、spinnaker が抽象化を行ってくれることにより、spinnaker の理解だけでクラウドサービスを使用できるようになっています。

spinnaker のインストールに関しては二種類の方法があります。
1つは、クイックスタート。 こちらは spinnaker を検証したい方用のためのものであり、本番環境などで使用するのには向きません。
もう1つは、 Halyard と呼ばれる spinnaker 専用のコマンドラインツールを使ってインストールする方法です。

Halyard 自体は、ローカルマシン、VM、Docker などにインストールすることを想定しており、12GB以上のメモリがある環境での使用が推奨されています。

spinnaker 自体に関しては、公式ドキュメントにて kubernetes での運用が想定されております。また、4コア以上、16GB以上のメモリでの動作が推奨されています。

spinnaker の設定自体はGUIでポチポチ入力していく形のようですが、Kubernetes Provider V2 が追加されたことにより、kubernetes のマニフェストファイルをベースにデプロイ設定を行えるようになりました。
これにより、GitOps をベースにしての開発も spinnaker で実施することができるようになりました。

ProgressiveDelivery

今まで話してきた Continuous Delivery ですが、その次の話として出てきているのが、Progressive Delivery(PD) と呼ばれる考え方です
こちらは weaveworks の blog でも話が出てきております。
Progressive Delivery を機能として構築するためには以下の機能が必要であると言われています。

  • ユーザーのセグメンテーション
  • トラフィックシフト管理
  • 観測とメトリクス
  • 自動化

上記の機能を達成するために使用されてくるのが Service Mesh と呼ばれる考え方で、これはサービス間の通信を処理するためのインフラストラクチャ層で制御する機能となります。
こちらは kubenetes の Container Network Interface の実装と近く、そのため kubenetes での新しいデリバリー方法として話題に出てきております。

各サービス間を Service Mesh 化して、小さくインフラ制御していくことにより、アプリケーション内の各サービス間のリクエストを計測することが容易になります。
すべてのリクエストのトレースが可能になり、何が起きているかがわかるようになります。
そしてどのようなリクエストが流れているかをトレースできるということは、どこにどれだけの負荷がかかっているかがわかるということです。そのため、高度なロードバランシング戦略が活用できるようになっていくわけですね。

サービスメッシュが提供する機能は以下のものを想定しているようです
  • サービスディスカバリー
  • ロードバランシング
  • 通信回復力
  • セキュリティ
  • 観測性
  • ルーティング制御
  • API

上記のような特性が提供されるため Progressive Delivery では、トラフィックを監視します。
その監視によりユーザーのセグメンテーションであったり、トラフィックシフト管理など、影響範囲を限定的にすることができます。
影響範囲を限定的にすることにより、早くアプリケーションを試していくためのデプロイが実施できるようになっていきます。

参考文献

さいごに

いかがだったでしょうか？

CI/CD だけではなく、そのさきの新しい Delivery の方法に私はワクワクしております。
今回は自分自身が関わっているプロジェクトでも kubernetes を使用しているため、カナリーリリースをやっていかないかっというエンジニアからの声の元。 spinnaker を使用しての CD の調査の結果の一部として記載させていただきました。

どんどんチャレンジしていける環境構築をSREチームの1人として推進していきます。 ドリコムでは一緒に働くメンバーを募集しています！
募集一覧はコチラを御覧ください！

関連記事