备忘录：云原生开发者日本第三次学习会议

下面是一个讲座的笔记

• Kubernetesで実現する高可用性システム — cndjp第3回

https://cnd.connpass.com/event/75617/

Kubernetes x 可用性的要点有四个。

1. 以分层思维来考虑
2. 微服务架构和Kubernetes的结合很合适
3. 发布的稳定性与服务的稳定性相关联
4. 基础设施的选择在云上进行

1. 进行层次分析考虑

微服务生态系统

• Susan J. Fowlerの「マイクロサービス・エコシステム」

https://www.susanjfowler.com/blog/2016/12/18/the-four-layers-of-microservice-architecture

|微服务|
|应用程序平台|<–CI/CD
|通信|<–服务之间的通信: RPC、API端点、服务发现、服务注册
|硬件|

在CI/CD和监控方面，还涉及到与k8s相关的部分。
在微服务部分也是同样的情况，通过结合使用k8s的功能来实现高可用性。

针对每个层次考虑故障防范措施

在处理中，通过划分层次并为每个项目确定优先级来采取相应的措施。

2. 微服务架构和Kubernetes非常搭配

是一种软件开发方法，将大型应用程序拆分成更小、更独立的部分，称为微服务。

• 大規模なシステムを小規模なサービスの組み合わせて実現するアーキテクチャ

 

• 複数のサービス群をHTTP(s)、RPC、非同期メッセージングなどにより疎結合に連携

 

• 変更の影響範囲をサービスにとどめることで、頻繁なアップデートを実現する

一個のバグ直すのにリリースなかなかできないことを避けるとか
モバイルアプリのようにどんどん新しい機能入れたりとか

参考）微服务架构的权衡

话语和利益领先，但权衡利弊已经相当深入人心。

在考虑在Kubernetes上实现可用性时，需要考虑的要点是什么？

• 各サービス単体としての可用性にフォーカスする

小規模に分かれている分だけやりやすい
例えば古典的な3総アプリの鯉宇正なら、従来と同じプラクティスが使える
k8sの機能をうまく活用する

サービスの境界（サービス同士の連携個所）に対策を施す

MSAならではの考慮点
サービスメッシュをうまく使う

在服务界限上发生的故障的例子

• 例)サービス障害の連鎖

シナリオ

サービスAから依存されるサービスBで障害が発生
サービスAでサービスBの応答町のスレッドが累積
スレッドが枯渇し、サービスAがリクエストに応答できない状態に（障害連鎖）
サービスBへのアクセス集中が解消しないため、サービスBが復旧困難に

対策

ヘルスチェック
サーキットブレーカー

健康检查和断路器

• サーキットブレーカー

リクエストに対する応答状態が一定の条件を満たした場合に、障害が発生したものとみなして、そのサービスへのリクエストを遮断する機構

ヘルスチェック

サービスの稼働状態を他サービスから確認するためのI/F
ヘルスチェック応答の結果を見てサーキットブレーカーを開くなどの判定を行う

应用于不同境界的障碍对策示例

• その他の例（代表的なもの）

バルクヘッドパターン
補正トランザクションパターン

いくつかのサービスをまたがってサービスの更新をしてそれぞれの更新が一貫性を保たなければいけない場合にどこかでこけたらロールバックする仕組み

参考資料

Building Fault Tolerant Microservices:

https://www.youtube.com/watch?v=pkO33elMwXRs

Azureアーキテクチャセンター >クラウドの設計パターン >回復性のパターン:

利用服务网格来进行服务边界的故障防治措施。

• サービスメッシュを利用するとサービス境界の障害対策を簡単に導入できる

 

• k8s+ Istio/Linkerd

Istioの定義では明確にサービスブレーカやリトライやカナリアをやることが述べられている。

次回kwskやる

聚焦于各项服务的可用性。

• 小規模な分だけやりやすくなっているはず

 

• 従来型の障害対策を実装する

SPOFがないか
障害時の回復性が十分か

k8sの機能をうまく利用する

スケールアウト型/分散型アーキテクチャのMWを積極利用

Cassandra/Kafka…

Podのスケーリングを活用して可用性構成を容易に実装

在Web3层架构中，

• セッションステートの分離

アプリケーションがセッションを持つことがありうまくスケールできないのでRedisのようなインメモリストレージに保存してスケールできるようにする
こういうことは古くから、クラウドがはやる前からやられている

Redis, GemFire…

これをやるとB/G Deployができるというメリットも出てくる
あとはMaster/SlaveがたのクラスタでDBを動かす

k8sのPodの拡張やStatefulSetを使うと簡単に作成可能

余談）1.9でGAになったばかりでまだ使われはじめ

R/Wのマスタが落ち、どれかがMasterに昇格したあとにマスタが復旧しても大丈夫

有状态副本集

一种K8s的对象

• Podに連番の名前が与えられる

 

• 永続領域、ネットワーク上の名前がPodに紐づけて管理される

 

障害復旧時、永続領域とNWの構成を保持したまま復旧する

对于SMKACK堆栈的情况

• Kafkaクラスタの例

Queueを分散して持っていてそれぞれがレプリカを持つ
k8sの機能により自動的に再起動
永続性やNW構成を維持したまま復帰する(Stateful）

可以建立一个可用性非常高的基础设施，即使Pod的一部分掉落也没有问题。

在SMKACK堆栈中的情况

• SMACK

Spark

Mesosk8s
Akka
Cassandra
Kafka

基本上是水平分散型架構。

亲自动手体验 (1)

• Apache Kafkaを利用したチャットアプリケーションを、Kubernetes上にデプロイ

https://github.com/oracle-japan/cndjp3/blob/master/handson1.md

3. 发布的稳定性决定了服务的稳定性。

应用平台的讨论

为什么发布与可用性有关？

• リリース->可用性に対するリスク

リリースは本番環境に変更を加えること
変更は傷害のリスク
MSAは頻繁にリリースされる

よいリリース

リリースするものがバグを含まない = 十分なテスト

lint、単体テスト、結合テスト、e2e
ステージング（負荷、カオステスト含む）、カナリー

テスト、リリース作業でミスをしない = 自動化

デプロイメント・パイプライン

部署管道的定义

甲骨文/工人

使用Istio进行金丝雀部署。

• Istioを使うとリクエストの流量を細かく設定可能

 

カナリーのコンテナを増やさずに、流量だけを徐々に増やすなど

4. 云选定是基础设施的选择。

Kubernetes的可用性配置

• マスターノードの冗長構成をとることで、コントロールプレーンをすべて冗長化

etcdのクラスタリング

自分で組むのはやめたほうが良い（と思う）

apiserverのクラスタリング

多分区构成

• 主要クラウドベンダーが提供するマネージドk8sサービスは、Multi Master構成をサポート

AKS
GKE
OpenShift Online

Zoneにまたがってマスター/ワーカーノードを配置してくれるものも

GKE
OpenShift Online

Oracle也计划发布k8s的托管服务

在进行尺码选择时请不要忘记考虑到可能的障碍。

• Kafkaなどノード障害後にデータリバランスを行う場合は、その時の負荷を考慮したサイジングが必要

CPUリソース、NW待機、ストレージ速度

障害復旧時間に影響するケースもある
クラウドサービスでは、性能が不安定なケースもあるので注意

VM同士の帯域の保証がない

亲手操作 (2)

• Kubernetes上にデプロイしたチャットアプリケーションに対して、カオステストを実施

https://github.com/oracle-japan/cndjp3/blob/master/handson2.md

下一次会告知

Kubernetes Network Deep Dive!

通知

• Slackチャネルにぜひご参加ください

http://bit.ly/cndjp-slack-invite