DigitalABOUTSERVICECASENEWSSPECIALISTRECRUITSPECIALIST多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。良祐2022.12.22クラウド技術検証kubernetesAzure1.はじめにNRIデジタルでは多くの大規模プロジェクトを推進していますが、新規性が高い技術を導入する場合はいつも多くの苦労があります。Service(以下、AKS)活用に向けた取り組みについてご紹介します。直近のプロジェクトの中での活動になりますが、大所帯のプロジェクトで関係者が多く、また発足当時は、Kubernetesも普及していたとはいえ業務系の中では比較的新しい仕組みでしたので、多くの関係者に、いかに広めるか、作ってもらうか、使ってもらうか、といった観点で取り組みを行っております。以下では、その内容を紹介します。導入フェーズの取り組みはじめに、導入フェーズの取り組みとして関係者にkubernetesに対する理解を促進する取り組みについて記載します。Kubernetesをプロジェクト関係者に広く進めようとするために、プロジェクト内で実施した勉強会やモチベーション維持の取り組みについてご紹介します。構築フェーズの取り組み次に、構築フェーズの取り組みについてです。構築スキームとしては、AKS他周辺のクラウドリソースも含めて効率的に構築できること、および、規模の割に短納期だったため新参者が短期間で習熟できること、が望まれる状況でした。端的に言うと、IaCツールを利用して構築スクリプトをテンプレート化して活用したのですが、その特徴や活用法について紹介します。運用フェーズの取り組み最後に、運用フェーズの取り組みについてです。主として、本番相当のレイテンシを注入した性能テストの高度化や、運用中に発生した障害を別環境で再現し早期是正を目指すために、カオスエンジニアリングツールの検証を進めています。本稿では、その検証の様子や、プロジェクト内での活用状況について紹介します。本稿の記載内容2.導入フェーズの取り組みここでは、広くプロジェクトメンバーにKubernetesへの理解を深めるために実施していた勉強会やそのモチベーション維持に関する取り組みを紹介します。回りを見渡すと、よくわからないので何もしない、と導入で躓くケースが多いように見られましたので、初期段階の導入は入り込みやすいような工夫が必要なように感じました。外部のハンズオン研修なども様々ありますが、それはそれとして、実際にはkubernetesの操作自体はCICDツール等で自動化される側面もあります。実務上で人間が担う役割は、設計やトラブル対応であることを考慮すると、kubernetesという系を俯瞰して、主要な構成要素やその役割、挙動を全体的に捉えることのほうが重要だと考えました。これらを踏まえて、特に初期段階としては、導入しやすく全体感を理解できるようにするために、専門用語を減らしたわかりやすい表現やイラストを用いて、基本的な内部構成や全体像を捉えることに注力した勉強会を実施しています。テーマも教科書の第1章:コンテナから、というのではなく、例えば「kubectlコマンドしたときの流れ」のように、通常の運用の中で発生する身近なところから進めていくようにしています。勉強会資料の例モチベーション維持モチベーション維持のためには、比較的届きやすく、かつ、実務上も有効なところに目標を設定することが良いと考えています。FoundationのCertificate(CKAD、CKA、CKS)に着目し、これらの取得を一つの軸として、それに向けたUdemy講座の紹介や演習環境等の整備、展開を行っています。試験自体は、実技形式で実務上必要不可欠な基本技能が問われるもので、難易度も程よく、基本事項を理解して、実行できる力が備わっていれば良いものとなっています。近年の在宅ワークの広がりにより、自己研鑽の時間も吊革につかまって本を読む時間から、机に向かってキーボードを叩く時間にシフトしやすくなり取り組みやすくなっているのではないかと思います。成果は得られており、今回の取り組みの中でも無事合格された方が出てきています。Certificateその他、kubernetesは設計要素やトラブルフォローのことを考えても、随所にネットワークが出てきて、大きな割合を占めるため、その理解にはネットワーク関連の知識習得が有効だと考えています。)や、Cisco社の入門資格であるCCNAやCCNPなどの取得もマイルストンとして取り上げています。こちらは教材等も実績豊富なものが多数あるので、過去問抜粋にはなりますが、ペースメーカとして1日1問チャット配信の活動を実施しています。こちらも今回の取り組みの中で無事合格者が出ています。ネットワーク関連の資格3.構築フェーズの取り組み構築フェーズに関しては、冒頭にも記載した通り、AKS他周辺のクラウドリソースも含めて効率的に構築できること、新参者が早期に戦力化するためにも短期間で習熟できることが実現できる構築フレームが必要な状況でした。対応として、IaCツールを用いた構築スクリプトのテンプレート化を行っていますが、その特徴と習熟に向けた活動を紹介します。テンプレートの特徴IaCツールとしては、Terraformを利用してテンプレート化を行いました。重点を置いたのは、後から参画した人が早期に習熟できる点であり、それを実現するために可能な限り単純化した構成にしています。その他の検討内容含めて、テンプレート化するにあたって整理した内容になります。具体的には、共通設定ファイル(main.tf)とインポートファイル(import.tf)、変数ファイル(variables.tf)だけのシンプルな構成として、利用の際は、原則として変数ファイルだけを編集し単純な繰り返しの表記のみでリソースが量産できる構成としました。結果として、効果は十分得られ、新しく入られた方にもスムーズに伝播し、プロジェクトを進めることができました。プロジェクト内では、コード化の文化も根付いてTerraformに続き、Ansible等その他周辺も整備されて、安定運用進める中での基礎となっています。習熟に向けた取り組み習熟に向けた取り組みとしては、演習会を実施しています。架空の要件を元に、前述のテンプレートを利用して、システム一式を構築する演習課題を作成しています。それを数回に渡り、設計・実装内容の説明、持ち帰り課題の実施、デモ実演等を実施していく形で実施しています。こちらは、プロジェクト関係であれば社内、社外問わず必要とされる場面で適宜実施して、テンプレートの普及に努めています。演習会の資料また得られた効果の例として、とある会社様においてテンプレートを展開し演習会を実施したところ、これまでの構築手法と比較して、生産性が約4倍程度の効果が見られました。こちらの会社様につきましては、来年度からの本格導入に向けて引き続きの支援を行っているところです。4.運用フェーズの取り組み運用フェーズにおける取り組みとして、カオスエンジニアリングツールの検証を進めています。主として、本番相当のレイテンシを注入することによる性能テストの高度化や、運用中に発生した障害を別環境で再現して早期是正を目指す活動となります。Studio)について記載します。Studioを利用することを想定しています。StudioChaosMeshは、2022/09時点でCNCFのincubatingに位置付けられているプロジェクトで、k8s上で動作するカオスエンジニアリングツールになります。ネットワークやPodに対する障害を発生させることができ、中でもネットワークに関しては、パケットのロスやドロップ、レイテンシ挿入など豊富なラインナップが揃っています。Studioは、2022/09時点でプレビューとなっていますが、こちらはAzureリソースに対する障害を発生させることができるサービスになります。対象にAKSが含まれており、その中では上述のChaosMeshが稼働する形になりますが、AKS以外のVMやCosmosDB、NSGに対する障害挿入もできるサービスとなります。実現できる障害ケースを下記に示します。Studioに関しては、担当プロジェクトがLinuxVMを扱うためLinuxVMに対応しているものをピックアップしていますが、WindowsVMも対象にするとさらに実現できる障害パターンは増えます。詳細は上記リンク先をご参照ください。MeshをAKSに導入し、Chaosの1つであるNetworkChaosの検証を行った例を示します。Studioとの統合は行わず、ChaosMesh単体で検証をしています。HelmのインストールAKSの操作端末にHelmをインストールします。Meshをインストールします。名前空間「chaos-testing」に一式インストールされますので、正常に稼働していることを確認します。86sNetworkChaos用のYAMLを作成する今回は10msの遅延を30秒間続ける設定としています。下記は簡単な例になりますが、ChaosMeshの機能としては、より詳細にパケットの向き(流入流出)であったり、ターゲットとするIPアドレスやFQDNを指定すること等も可能です。実務上はこれらを指定して障害の再現や性能テスト環境を構築することになると思います。applyすることで、Chaosが開始されます。今回は、下記のような構成の環境で、踏み台サーバからAKS上のPodに対してpingをNetworkChaosの実行前と実行中のタイミングで実行しました。検証時の構成図その結果を記載します。msChaos実行前は約1msでの応答となっています。msChaos実行中は、バラつきはありますが、約10msでの応答となり、設定した10msの遅延が有効に効いていることが確認できます。実務では、下記のような構成、定義を用いて、AKS上のオンラインサービスから特定のDBへの通信のみにレイテンシを挿入した状態を作り、性能テストを実施しています。本番環境においては、接続経路のNW品質や対向DBの処理性能などの問題で、特定の経路のみレイテンシが発生する場合があり、性能テストではそのレイテンシを含めた性能測定が必要になります。上記の定義では、AKSからDatabaseVMに至る経路についてのみレイテンシを挿入し、他のSQLDBやExternalAPI接続先に関してはレイテンシを設定しない状況を作り出しています。ChaosMeshのNetworkChaosでは、パケットの向きをdirectionというパラメータで指定でき、デフォルト値は出力方向の「to」となっています。externalTargetsは、directionがtoのときのみ作用するため、今回は明示的にdirectionを指定しない形としています。このような環境でテストを行うことで、より本番環境に近い状態で精度の高い性能測定をすることができ、繁忙期対策と安定運用に貢献しています。Service(以下、AKS)活用に向けた取り組みについてご紹介しました。これらの取り組みもスタートラインであり、PDCAサイクル回して試行錯誤しているところですが、新規性の高い技術をものにして飛躍するために超えねばならない壁であり、腕の見せ所でもあります。本稿で取り上げた取り組みが、AKSやその他Kubernetesサービスの導入、もしくは、同じく新規性の高い技術採用に直面した際のヒントになれば幸いです。