SPECIALIST

多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。

BACK

大規模プロジェクトでのAKS活用に向けた取り組みの紹介

荒井 良祐

2022.12.22

１．はじめに

NRIデジタルでは多くの大規模プロジェクトを推進していますが、新規性が高い技術を導入する場合はいつも多くの苦労があります。
本稿では、そのような新技術導入のプロジェクト例として、Azure Kubernetes Service（以下、AKS）活用に向けた取り組みについてご紹介します。
直近のプロジェクトの中での活動になりますが、大所帯のプロジェクトで関係者が多く、また発足当時は、Kubernetesも普及していたとはいえ業務系の中では比較的新しい仕組みでしたので、多くの関係者に、いかに広めるか、作ってもらうか、使ってもらうか、といった観点で取り組みを行っております。
以下では、その内容を紹介します。

導入フェーズの取り組み

はじめに、導入フェーズの取り組みとして関係者にkubernetesに対する理解を促進する取り組みについて記載します。
Kubernetesをプロジェクト関係者に広く進めようとするために、プロジェクト内で実施した勉強会やモチベーション維持の取り組みについてご紹介します。

構築フェーズの取り組み

次に、構築フェーズの取り組みについてです。
構築スキームとしては、AKS他周辺のクラウドリソースも含めて効率的に構築できること、および、規模の割に短納期だったため新参者が短期間で習熟できること、が望まれる状況でした。
端的に言うと、IaCツールを利用して構築スクリプトをテンプレート化して活用したのですが、その特徴や活用法について紹介します。

運用フェーズの取り組み

最後に、運用フェーズの取り組みについてです。
主として、本番相当のレイテンシを注入した性能テストの高度化や、運用中に発生した障害を別環境で再現し早期是正を目指すために、カオスエンジニアリングツールの検証を進めています。
本稿では、その検証の様子や、プロジェクト内での活用状況について紹介します。

本稿の記載内容

２．導入フェーズの取り組み

ここでは、広くプロジェクトメンバーにKubernetesへの理解を深めるために実施していた勉強会やそのモチベーション維持に関する取り組みを紹介します。

勉強会

回りを見渡すと、よくわからないので何もしない、と導入で躓くケースが多いように見られましたので、初期段階の導入は入り込みやすいような工夫が必要なように感じました。
また、外部のハンズオン研修なども様々ありますが、それはそれとして、実際にはkubernetesの操作自体はCICDツール等で自動化される側面もあります。実務上で人間が担う役割は、設計やトラブル対応であることを考慮すると、kubernetesという系を俯瞰して、主要な構成要素やその役割、挙動を全体的に捉えることのほうが重要だと考えました。
これらを踏まえて、特に初期段階としては、導入しやすく全体感を理解できるようにするために、専門用語を減らしたわかりやすい表現やイラストを用いて、基本的な内部構成や全体像を捉えることに注力した勉強会を実施しています。
テーマも教科書の第１章：コンテナから、というのではなく、例えば「kubectlコマンドしたときの流れ」のように、通常の運用の中で発生する身近なところから進めていくようにしています。

勉強会資料の例

モチベーション維持

モチベーション維持のためには、比較的届きやすく、かつ、実務上も有効なところに目標を設定することが良いと考えています。そこで、Kubernetes関連の資格Linux FoundationのCertificate（CKAD、CKA、CKS）に着目し、これらの取得を一つの軸として、それに向けたUdemy講座の紹介や演習環境等の整備、展開を行っています。
試験自体は、実技形式で実務上必要不可欠な基本技能が問われるもので、難易度も程よく、基本事項を理解して、実行できる力が備わっていれば良いものとなっています。
近年の在宅ワークの広がりにより、自己研鑽の時間も吊革につかまって本を読む時間から、机に向かってキーボードを叩く時間にシフトしやすくなり取り組みやすくなっているのではないかと思います。
成果は得られており、今回の取り組みの中でも無事合格された方が出てきています。

Linux Foundation の kubernetes Certificate

その他、kubernetesは設計要素やトラブルフォローのことを考えても、随所にネットワークが出てきて、大きな割合を占めるため、その理解にはネットワーク関連の知識習得が有効だと考えています。
こちらは、これまでの自己研鑽の継続とはなりますが、IPAの高度情報処理試験（ネットワークスペシャリスト、または、NW分野の出題が多い情報処理安全確保支援士）や、Cisco社の入門資格であるCCNAやCCNPなどの取得もマイルストンとして取り上げています。こちらは教材等も実績豊富なものが多数あるので、過去問抜粋にはなりますが、ペースメーカとして1日1問チャット配信の活動を実施しています。こちらも今回の取り組みの中で無事合格者が出ています。

ネットワーク関連の資格

３．構築フェーズの取り組み

構築フェーズに関しては、冒頭にも記載した通り、AKS他周辺のクラウドリソースも含めて効率的に構築できること、新参者が早期に戦力化するためにも短期間で習熟できることが実現できる構築フレームが必要な状況でした。
対応として、IaCツールを用いた構築スクリプトのテンプレート化を行っていますが、その特徴と習熟に向けた活動を紹介します。

テンプレートの特徴

IaCツールとしては、Terraformを利用してテンプレート化を行いました。
特に重点を置いたのは、後から参画した人が早期に習熟できる点であり、それを実現するために可能な限り単純化した構成にしています。その他の検討内容含めて、テンプレート化するにあたって整理した内容になります。

テンプレート化する際に検討した内容

具体的には、共通設定ファイル（main.tf）とインポートファイル（import.tf）、変数ファイル（variables.tf）だけのシンプルな構成として、利用の際は、原則として変数ファイルだけを編集し単純な繰り返しの表記のみでリソースが量産できる構成としました。

Terraformテンプレートの一例

結果として、効果は十分得られ、新しく入られた方にもスムーズに伝播し、プロジェクトを進めることができました。また、プロジェクト内では、コード化の文化も根付いてTerraformに続き、Ansible等その他周辺も整備されて、安定運用進める中での基礎となっています。

習熟に向けた取り組み

習熟に向けた取り組みとしては、演習会を実施しています。架空の要件を元に、前述のテンプレートを利用して、システム一式を構築する演習課題を作成しています。それを数回に渡り、設計・実装内容の説明、持ち帰り課題の実施、デモ実演等を実施していく形で実施しています。こちらは、プロジェクト関係であれば社内、社外問わず必要とされる場面で適宜実施して、テンプレートの普及に努めています。

演習会の資料

また得られた効果の例として、とある会社様においてテンプレートを展開し演習会を実施したところ、これまでの構築手法と比較して、生産性が約4倍程度の効果が見られました。こちらの会社様につきましては、来年度からの本格導入に向けて引き続きの支援を行っているところです。

４．運用フェーズの取り組み

運用フェーズにおける取り組みとして、カオスエンジニアリングツールの検証を進めています。
主として、本番相当のレイテンシを注入することによる性能テストの高度化や、運用中に発生した障害を別環境で再現して早期是正を目指す活動となります。
ここでは、現在検証を進めているカオスエンジニアリングツール（Chaos Mesh、Chaos Studio）について記載します。
AKS上の障害再現用には、Chaos Mesh、周辺のAzureリソースの障害再現には、Azure Chaos Studioを利用することを想定しています。

ChaosMesh
Azure Chaos Studio

ChaosMeshは、2022/09時点でCNCFのincubatingに位置付けられているプロジェクトで、k8s上で動作するカオスエンジニアリングツールになります。ネットワークやPodに対する障害を発生させることができ、中でもネットワークに関しては、パケットのロスやドロップ、レイテンシ挿入など豊富なラインナップが揃っています。
Azure Chaos Studioは、2022/09時点でプレビューとなっていますが、こちらはAzureリソースに対する障害を発生させることができるサービスになります。対象にAKSが含まれており、その中では上述のChaosMeshが稼働する形になりますが、AKS以外のVMやCosmosDB、NSGに対する障害挿入もできるサービスとなります。
実現できる障害ケースを下記に示します。Chaos Studioに関しては、担当プロジェクトがLinuxVMを扱うためLinuxVMに対応しているものをピックアップしていますが、WindowsVMも対象にするとさらに実現できる障害パターンは増えます。詳細は上記リンク先をご参照ください。

再現できる主要な障害パターン

障害パターン 内容
Network Chaos Podへの流入パケット、Podからの流出パケットに対して、遅延、順序変更、損失、複製、破壊、帯域制限
Pod Chaos Podの停止、削除、Pod内Containerの削除
Stress Chaos PodのCPU負荷、Memory負荷
timeChaos Podのシステムクロック変更
HTTPChaos PodへのHTTP通信、PodからのHTTP通信に対して、破棄、遅延、改変、情報付加
IOChaos Pod内でのディスクアクセスに対して、IO遅延、IO失敗、ファイル属性変更、write, readのシステムコール改変
DNSChaos K8s内部のDNSにエラーやランダムなIPアドレス応答

障害パターン 内容
CPUPressure LinuxVMにCPU負荷をかける
PhysicalMemoryPressure LinuxVMの物理Memoryの負荷を増大する
LinuxDiskIOPressure LinuxVMにディスクIO負荷をかける
StressNg Linux VMにインストールしたstress-ngに任意のコマンドを送信し、負荷をかける
Shutdown Linux VMをシャットダウンする
KillProcess LinuxVM内で稼働するプロセスを停止する
SecurityRule ネットワークセキュリティグループ規則の操作を行う

以下では、Chaos MeshをAKSに導入し、Chaosの1つであるNetworkChaosの検証を行った例を示します。
なお、Azure Chaos Studioとの統合は行わず、ChaosMesh単体で検証をしています。

Helmのインストール

AKSの操作端末にHelmをインストールします。
参考）Helm | Installing Helm

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3

$ chmod 700 get_helm.sh

$ ./get_helm.sh

$ helm version
version.BuildInfo{Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.5"}

AKSにChaos Meshをインストール

AKSにChaos Meshをインストールします。
参考）Azure CLIでAzure Chaos Studioを使い、AKS Chaos Mesh障害を使う実験を作成する

$ az aks get-credentials -g rg-chaos -n aks-chaos

$ helm repo add chaos-mesh https://charts.chaos-mesh.org

$ helm repo update

$ kubectl create ns chaos-testing --context aks-chaos

$ helm install chaos-mesh chaos-mesh/chaos-mesh --namespace=chaos-testing --version 2.1.3 --set chaosDaemon.runtime=containerd --set chaosDaemon.socketPath=/run/containerd/containerd.sock

[output]
NAME: chaos-mesh
LAST DEPLOYED: Fri Feb 25 12:37:21 2022
NAMESPACE: chaos-testing
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Make sure chaos-mesh components are running
   kubectl get pods --namespace chaos-testing -l app.kubernetes.io/instance=chaos-mesh

Chaos Meshインストール後の確認

名前空間「chaos-testing」に一式インストールされますので、正常に稼働していることを確認します。

$ kubectl get pods -n chaos-testing --watch
NAME                                       READY   STATUS    RESTARTS   AGE
chaos-controller-manager-99ccb5fbd-flx9b   1/1     Running   0          86s
chaos-controller-manager-99ccb5fbd-kzhxm   1/1     Running   0          86s
chaos-controller-manager-99ccb5fbd-t4v5d   1/1     Running   0          86s
chaos-daemon-bg9xl                         1/1     Running   0          86s
chaos-daemon-q8r7z                         1/1     Running   0          86s
chaos-daemon-xgxtc                         1/1     Running   0          86s
chaos-dashboard-7887bf5fcf-n4h5l           1/1     Running   0          86s

NetworkChaos用のYAMLを作成する

今回は10msの遅延を30秒間続ける設定としています。
下記は簡単な例になりますが、ChaosMeshの機能としては、より詳細にパケットの向き（流入流出）であったり、ターゲットとするIPアドレスやFQDNを指定すること等も可能です。実務上はこれらを指定して障害の再現や性能テスト環境を構築することになると思います。

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: delay
  namespace: chaos-testing
spec:
  action: delay
  mode: all
  duration: '30s'
  selector:
    namespaces:
      - default
  delay:
    latency: '10ms'
    correlation: '100'
    jitter: '0ms'

このYAMLをkubectl applyすることで、Chaosが開始されます。
今回は、下記のような構成の環境で、踏み台サーバからAKS上のPodに対してpingをNetworkChaosの実行前と実行中のタイミングで実行しました。

検証時の構成図

その結果を記載します。

Chaos実行前の結果

64 bytes from 10.3.1.55: icmp_seq=1 ttl=63 time=1.43 ms
64 bytes from 10.3.1.55: icmp_seq=2 ttl=63 time=0.883 ms
64 bytes from 10.3.1.55: icmp_seq=3 ttl=63 time=0.935 ms
64 bytes from 10.3.1.55: icmp_seq=4 ttl=63 time=0.844 ms
64 bytes from 10.3.1.55: icmp_seq=5 ttl=63 time=0.747 ms
64 bytes from 10.3.1.55: icmp_seq=6 ttl=63 time=0.914 ms
64 bytes from 10.3.1.55: icmp_seq=7 ttl=63 time=0.779 ms
64 bytes from 10.3.1.55: icmp_seq=8 ttl=63 time=0.731 ms
64 bytes from 10.3.1.55: icmp_seq=9 ttl=63 time=0.666 ms

Chaos実行前は約1msでの応答となっています。

Chaos実行中の結果

64 bytes from 10.3.1.55: icmp_seq=21 ttl=63 time=10.7 ms
64 bytes from 10.3.1.55: icmp_seq=22 ttl=63 time=11.0 ms
64 bytes from 10.3.1.55: icmp_seq=23 ttl=63 time=10.8 ms
64 bytes from 10.3.1.55: icmp_seq=24 ttl=63 time=10.9 ms
64 bytes from 10.3.1.55: icmp_seq=25 ttl=63 time=10.9 ms
64 bytes from 10.3.1.55: icmp_seq=26 ttl=63 time=10.9 ms
64 bytes from 10.3.1.55: icmp_seq=27 ttl=63 time=14.9 ms
64 bytes from 10.3.1.55: icmp_seq=28 ttl=63 time=11.0 ms
64 bytes from 10.3.1.55: icmp_seq=29 ttl=63 time=11.0 ms

Chaos実行中は、バラつきはありますが、約10msでの応答となり、設定した10msの遅延が有効に効いていることが確認できます。

実務での利用例

実務では、下記のような構成、定義を用いて、AKS上のオンラインサービスから特定のDBへの通信のみにレイテンシを挿入した状態を作り、性能テストを実施しています。
本番環境においては、接続経路のNW品質や対向DBの処理性能などの問題で、特定の経路のみレイテンシが発生する場合があり、性能テストではそのレイテンシを含めた性能測定が必要になります。

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: delay
  namespace: chaos-testing
spec:
  action: delay
  mode: all
  duration: '21600s'
  selector:
    namespaces:
      - default
  delay:
    latency: '10ms'
    correlation: '100'
    jitter: '0ms'
  externalTargets: ["10.0.0.5"]
構成図

上記の定義では、AKSからDatabaseVMに至る経路についてのみレイテンシを挿入し、他のSQLDBやExternalAPI接続先に関してはレイテンシを設定しない状況を作り出しています。
なお、ChaosMeshのNetworkChaosでは、パケットの向きをdirectionというパラメータで指定でき、デフォルト値は出力方向の「to」となっています。externalTargetsは、directionがtoのときのみ作用するため、今回は明示的にdirectionを指定しない形としています。
このような環境でテストを行うことで、より本番環境に近い状態で精度の高い性能測定をすることができ、繁忙期対策と安定運用に貢献しています。

５．おわりに

本稿では、Azure Kubernetes Service（以下、AKS）活用に向けた取り組みについてご紹介しました。
これらの取り組みもスタートラインであり、PDCAサイクル回して試行錯誤しているところですが、新規性の高い技術をものにして飛躍するために超えねばならない壁であり、腕の見せ所でもあります。
本稿で取り上げた取り組みが、AKSやその他Kubernetesサービスの導入、もしくは、同じく新規性の高い技術採用に直面した際のヒントになれば幸いです。