カナリヤリリース
新規プロダクトやサービスを本番環境の一部分にデプロイし、先に一部のユーザに提供することで新機能のフィードバッグをいち早く得ることで機能としての必要性を受け取ったうえで、全てのデプロイを行うという方法です。
Spinnakerを使ったカナリーリリースの自動評価 #spinnaker #kayenta
CDツールであるSpinnakerを使えば、Kubernetes(k8s)へのカナリーリリースだけでなく、カナリーリリースを自動評価して新バージョンの良し悪しを判断、その後の本番でのスケールアウトまで自動で行うことができる。
Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.
Similar to a BlueGreenDeployment, you start by deploying the new version of your software to a subset of your infrastructure, to which no users are routed.
(書籍)プロダクションレディマイクロサービス ――運用に強い本番対応システムの実装と標準化
- ステージング環境、カナリヤ環境、本番環境 という3つの環境からなるシステムを考える。
- ステージング環境で必要なテストを終えたプロダクトは、次にカナリヤ環境にデプロイされる。
- カナリヤ環境で、本番のトラフィックからサンプリングされた少数のトラフィックに基づき、本番環境にデプロイするかを決める。あるいは、徐々にトラフィックをあげていき、100%にする(つまりカナリヤ環境がそのまま本番環境になる)。
- カナリヤ環境に必要な要素：
- 本番のトラフィックの5%から10%ほどをカナリヤ環境に流すロードバランシングのシステム。
- 自動ロールバック。本番環境のサーバプールで動かしていることを忘れてはいけない。
- 本番環境にしていく指標や閾値の設定、それに伴うモニタリングシステム
カオスエンジニアリング
カオステストともいわれる。本番環境(あるいはステージング環境)で意図的に、またランダムに障害を発生させ、システムの可用性や障害対応のフローを日常的に確認する手法。
Chaos Engineering の導入によってサービスの耐障害性に自信を持てるようにします。日常的に障害をエミュレートする事によってサービスの耐障害性が高いことを開発者に要求します。
ソフトウェアテストなどの文脈では良く言われますが、不具合は発見が遅れれば遅れるほど、その不具合を修正するコストはかさむことになります。
可用性の高いシステムを作るために、不具合を早く発見し改善していくために Chaos Engineering を導入していきます。
Netflix 驚異的なトラブル対応 カオスエンジニアリングとは、何か？
「カオスエンジニアリング」とは、
1. 「自動復旧システム」が動作していることが前提
2. 動作中にわざとサーバーダウンや応答遅延などの障害を発生させる。
⇒「カオスエクスペリメント」と呼ばれています。
3. 「カオスエクスペリメント」を本番稼働中に日常的に発生させる。
4. 自動復旧システムが復旧できるか確認する。
Netflixが公開しているカオスエンジニアリングのツール: The Netflix Simian Army
カオスエンジニアリングをする前提には、システムは当然以下を満たしておく必要がある。
- SPOFを完全に除去されている状態。一つのリージョンがすべて破壊されたとしても大丈夫な状態。
- 障害が起きても自動復旧してユーザに全く影響がでない状態。日曜日の午前3時に障害が起きたことすら気づかない状態。
BlueGreenデプロイ
「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説
デプロイメントの自動化における課題の1つは、ソフトウェアをテストの最終段階からプロダクションへともっていくカットオーバーそれ自体にある。通常はこの作業を迅速に行うことで、ダウンタイムを最小化しなければならない。blue-green deploymentはこれを、可能な限り同じにした2つの本番環境によって確実に行うようにしている。
例えばいまBlue環境がライブで、新リリース用のソフトウェアがテストの最終段階にあるとしよう。そのソフトウェアがGreen環境で稼働し始めたら、ルータを切り替えて外部からのリクエストをGreen環境へ行くようにする。するとBlue環境はアイドル状態になる。
この手法の優れている点は、ホットスタンバイの実装と基本的には同じ仕組みであることだ。そのため、リリースごとにディザスタリカバリの手順でテストできる（災害が発生するよりも頻繁にリリースしてもらいたいと私は思っているが）。
BlueGreenをするために：
- そもそもどうやって実現するのか？
- データベースはどうするのか？
他にも -> IIJ GIOベストプラクティス － リファレンスアーキテクチャ Blue-Green Deployment
Kubernetesを使ってBlueGreenDeploy -> KubernetesでIngressを利用してBlue/Greenデプロイメントを実現する
あるいはSpinnakerを使う方式。
DevOps
有名なやつ -> 10+ Deploys Per Day: Dev and Ops
DevOps（デブオプス[1]）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。
アーキテクチャ関連 -> microservice
DevOpsを効果的に実践するためには、ソフトウェア・アプリケーションはアーキテクチャ上重大な要求（ASR）と呼ばれている要求を満たす必要がある。展開性、修正可能性、テスト容易性、と監視性などASRは高い優先度を必要とする[9] 基本的には、どのようなアーキテクチャ・スタイルでも、DevOpsを実践することは可能である。しかし、展開されるシステムを構築する場合のマイクロ・サービスのアーキテクチャ・スタイルが標準になりつつある。各サービスのサイズが小さいため扱いやすくなり、そして、継続的な編集を通じて、各サービスのアーキテクチャが見えるようになる。そのため、大きな初期設計が不要となり、ソフトウェアを早期に継続的にリリースすることができる。
microservice
これなら分かる！ マイクロサービス（入門編）～モノリスと比較した特徴、利点と課題
一言でいうと：マイクロサービスとは
「マイクロサービス・アーキテクチャ」または単に「マイクロサービス」と呼ばれる開発手法。それがどのようなものかを一言で定義するなら、「複数の独立した機能を組み合わせることで、一つの処理を実現するアーキテクチャ」であると言えます。ポイントは、一つの処理を実現するのが一つの機能ではなく、複数の機能であるというところです。
CacooはなぜKubernetesによるmicroservicesへの道を選んだのか？
microservices のメリット
そこで、 microservices 化する道を選びました。一般的に、 microservices には以下のようなメリットがあると考えています。
サービスごとに技術を選択できる
部分的な変更が容易になる
(うまく設計できれば)サーバーリソースを最適化できる
(うまく設計できれば)堅牢なシステムになる
アーキテクチャパターンも提案されている -> What are microservices?
messagingを基調としたデザインパターンとしてのEnterprise Integration Pattern(EIP) -> How integration patterns impact your microservices architecture
kubernetes
上記の文脈ではほぼkubernetesの利用が前提となる
kubernetesで何ができるか。
- スケジューリング
- ローリングアップデート
- セルフヒーリング
- オートスケーリング
- コンテナの死活監視
- ロードバランシング
- データの管理
- ワークロード管理
- ログ管理
- Infrastructure as Code
- その他のエコシステムとの連携や拡張
(cf. (書籍)Kubernetes完全ガイド (impress top gear)
AzureやAWS, Pivotal, IBM によってマネージドサービスが展開されている。もちろんGoogleも。
Kubernetesのkeyword。抜粋。とにかく巨大なので学ぶものは沢山ある。
- 基礎: Workload, Pod, ReplicaSet, Deployment, DamonSet, StatefulSet, Job, CronJob, ...
- ネットワーキング: (Overlay Network,) Service, Ingress, LoadBalancer, ...
- クラスタの分離: Namespace, ...
- ストレージ: ConfigMap, Vlume, PV, PVC, ...
- セキュリティ: ServiceAccounst, ...
- マニフェストの汎用化: Helm, ...
- モニタリング: Datadog, Prometheus, ...
- ログ: Fluentd, Datadog Agent, ...
- CI/CD: Spinnaker, Skaffold, Jenkins X, ...
- マイクロサービス: Istio, Spring Cloud Data Flow, ...
- kubernetesのアーキテクチャ: etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy, kube-dns, ...
そして何よりもまずコンテナの概念が先立つ。-> Docker(Mobby)
活用例:
* 世界におけるKubernetes活用状況と企業向けプライベートクラウド基盤
* Kubernetes User Case Studies