とある企業さんとのカジュアル面談時に、 
面談相手のエンジニアへキャッチアップはどのようにしているかを聞いてみたら、 
下記のシステム設計などをみたりしていると教えてもらったので、 
その中から興味があった、負荷分散の項目を追ってみようと思う。 

 

## 一般的な負荷分散アルゴリズム(ロードバランサーを使用した場合)
1. ラウンドロビン

![Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/roundrobin.webp "Round Robin")

ユーザーからのリクエストに対して、順番にサーバーへ送信される。 
簡単な設計だが、サーバー側の負荷を考慮しないので、サーバーAが死んだ場合もリクエストが送られてしまう。

 

2. スティッキーラウンドロビン

![Sticky Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/stickyRoundRobin.webp "Sticky Round Robin")

ユーザーからのリクエストはずっと同じサーバーに送信するようにする。 
セッションパーシステムを実現するためのアルゴリズム。 
特にユーザーのセッション状態を維持してサービスを展開したいもの(ECサイトなどなど)に有効。 
しかし、これも同じサーバーに接続し続けるのでサーバーが死んだらエラーになってしまい、負荷が均等に分散されない。 
※ セッションパーシステム 
特定のユーザーから来る一連のリクエストを同じサーバーに振り分けること。 
 
下記でセッションを固定している 
・IPアドレスベースでセッションを固定 
・ユーザーにセッションIDを割り当てて固定 
・Cookieを使用してセッション情報を保持して固定

 

3. 加重ラウンドロビン

![Weighted Round Robin](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/WeightedRoundRobin.webp "Weighted Round Robin")

各サービスに対して重みを設定する。 
図だとServiceAに80%,その他に10%ずつ重みを設定している。 
そうすると80%までのリクエストはServiceAに、81%〜90%はServiceB、90%〜100%はServiceCに割り振られる。 
サーバーの能力に応じて重みを設定することが大事。

 

4. ハッシュ

![IP URL Hash](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/ipUrlHash.webp "IP URL Hash")

受信トラフィックの送信元と送信先のIPアドレス、URLを組み合わせて、 
数学的関数を使用しハッシュに変換。そのハッシュの値で指定したサーバーに割り振られる。
図だと、req1, req2のipアドレスやURLが0になると、ServiceAのインスタンスにルーティングされる。

 

5. 最小接続数

![Least Connections](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/leastConnections.webp "Least Connections")

同時接続数が最も少ないサービスに送信される。
サーバー間の負荷を均等に分散できるため動的な環境に適している。

 


6. 最短応答時間

![Least Time](https://zaki-dev-image-bucket.s3.ap-northeast-1.amazonaws.com/article-images/load-distribution/leastTime.webp "Least Time")

最もレスポンス時間が短いサーバーに送信される。 
リアルタイムにサーバーのパフォーマンスを監視し、動的に負荷を分散している。

 

※ロードバランサーは、複数サーバー間でのトラフィックを効率的に分散する

## まとめ
なんとなくで負荷分散している部分もあったので、
こういったアルゴリズムを取り入いれ品質を高めていこうと思う今日この頃。

【システム設計1】 負荷分散アルゴリズムについて考えてみる

仕事でGKEを使用する必要があるので、 
自分用にまとめていきたいと思います。

便利な機能
- リリースチャネル
- Nodeの自動アップデート、自動修復機能
- Nodeの自動プロビジョニング機能(ノードのインスタンスタイプを自動で決定してくれる)など

 

# Nodeについて
- GCE(Goole Compute Engine)が利用されている
- GCEはプリエンプティブルインスタンス(起動時間に24時間制限ありの低コストインスタンス)
- プリエンプティブルインスタンスの場合、ちゃんと設定しないとNodeが停止することがある
- プリエンプティブルインスタンスの場合、24時間後に全Nodeが停止する可能性があるため、Preempible-killer(ランダムに徐々にNodeを入れ替える)の利用を検討する

 

# GKE
- Cloud Loggingがデフォルトで連携
- 高性能なHttp loadbalancer(Ingress)
- GPUの利用もできる

 

# NodePoolについて
クラスタ内のNodeにラベル付けし、グルーピングするような機能
ex:
- vCPU数が多い => NodePoolA
- メモリ容量が多い => NodePoolB
こんな感じでグループ分けできる

## GCP SDK
```bash
# GCP SDK install
curl https://sdk.cloud.google.com | bash

# gcloudコマンドを使用できるようにシェルを再起動
exec -l $SHELL

# gcloud CLI認証
gcloud init

# GKEで利用可能なk8sのバージョンを確認
gcloud container get-server-config --zone asia-northeast1-a
```

## クラスターを作成
```bash
gcloud container clusters create k8s \
--cluster-version 1.29.7-gke.1104000 \
--zone asia-northeast1-a \
--num-nodes 3

# gke-gcloud-auth-pluginが見つからないとエラーになるとき
gcloud components update
gcloud components install gke-gcloud-auth-plugin

# 上記で作成したk8sクラスターにアクセス
gcloud container clusters get-credentials k8s --zone asia-northeast1-a
```
Fetching cluster endpoint and auth data.
kubeconfig entry generated for k8s.
👆のように`k8s`の名前になっていればOK

 

## GCPユーザー
```bash
# 現在のユーザー確認
gcloud config get-value core/account
# 変更がなかったら環境変数に追加
GCP_USER=`gcloud config get-value core/account`

# 上記のユーザーにクラスタ管理者権限を付与
kubectl create --save-config clusterrolebinding iam-cluster-admin-binding \
--clusterrole=cluster-admin \
--user=${GCP_USER}
```
clusterrolebinding.rbac.authorization.k8s.io/iam-cluster-admin-binding created
👆このようになればOK

 

## クラスターの削除
```bash
gcloud container clusters delete k8s --zone asia-northeast1-a
```
 

GKEの詳細情報
https://cloud.google.com/kubernetes-engine/?hl=ja

## その他のプライグラウンド
- 最大５台のインスタンスの起動OK
- 連続利用時間が4時間まで

https://labs.play-with-k8s.com/

Zaki-dev

SREの記事

【システム設計1】負荷分散アルゴリズムについて考えてみる

GKEでクラスターの作成から削除まで

SREの記事

【システム設計1】 負荷分散アルゴリズムについて考えてみる

GKEでクラスターの作成から削除まで

【システム設計1】負荷分散アルゴリズムについて考えてみる