銀の光と碧い空

クラウドなインフラとC#なアプリ開発の狭間にいるエンジニアの日々

Azure Chaos Studio を試してみる サービス直接ターゲット編

f:id:tanaka733:20220118233433p:plain 先日、カオスエンジニアリングをマネージドサービスとして提供するAzure Chaos Studioが発表され、プレビューとして利用できるようになっています。

azure.microsoft.com

docs.microsoft.com

せっかくなので試してみようと思い、いろいろやった結果をまとめておきます。

Chaos Studioの概念

ドキュメントでいうとここからのセクションに説明されています。

docs.microsoft.com

一番大きな単位が「カオス実験」で、どんな障害をどんなリソースに実行するかが記述されています。 どんな障害を「ロジック」として定義し、どんなリソースにを「セレクター」として定義します。この2つがカオス実験を構成する単位です。 ロジックは1つずつ逐次実行する「ステップ」から構成され、ステップは同時に実行される「分岐(Branch)」から構成されます。 分岐は対象となるリソースをさらに定義するセレクターと、なにを実行するかの「アクション」で構成されます。 アクションは、障害もしくは待機の2種類があります。 これらの組み合わせで1つの実験を定義し、実行することになります。

現在利用できる障害は以下の3種類にわけられるようです。

  • サービス直接ターゲット: Azureのサービスに直接作用する
  • エージェントベース: OSにインストールしたエージェントが作用する
  • Chaos Mesh: AKSクラスター上のkubernetesリソースにChaos Meshを利用して作用する

まず、サービス直接ターゲットを使ったものを試してみました。

CosmosDBにサービス直接ターゲットを設定して障害を起こす

試したアクションはCosmosDBをFailoverさせるものです。基本的にはこのドキュメントに沿って設定すればOKです。が、いくつかはまったところがあるのと、実は最終的に実験の結果がFailedになってしまい未解決です。

docs.microsoft.com

まずはCosmosDBを用意します。Failoverさせることから、読み取りリージョンを1つ以上追加しておかないとあとで設定できなくなります。 f:id:tanaka733:20220118232721p:plain f:id:tanaka733:20220118191744p:plain

空だとさみしいので、コンテナとアイテムを用意しておきました。実験を実行するだけの場合、なくてもかまいません。

f:id:tanaka733:20220118185203p:plain

まず、Azure Chaos Studioのページから対象となるリソースを選択します。そして、大事なことですが、ポータルの言語を英語にしておきます。Previewのせいなのか、日本語だとロジックがうまく実行できませんでした。最初日本語で作成していたので画面キャプチャは日本語になっています。

f:id:tanaka733:20220118185259p:plain

実験を作成します。このときのリソースグループとリージョンは対象と一致していなくてもよいはずですが、今回は同じものを選んでいます。

f:id:tanaka733:20220118185748p:plain

実験を作成したら、ロジックを作成します。ステップとブランチ1つの中に、障害アクションを1つ作成します。

f:id:tanaka733:20220118185839p:plain

翻訳の表記ゆれをしていますが、フォールトの選択で障害の種類を選びます。CosmosDB Failverを選びます。

f:id:tanaka733:20220118185903p:plain

どのリージョンにFailoverさせるかを選択します。ここで注意しないといけないのは、Failover先は対象のCosmosDBの読み取りリージョンとして追加されたものでないといけません。そして、ポータルの言語が日本語のときの問題はここで発生しました。例えばここで「英国西部」を選択していますが、すると「英国西部」という値がアクションに設定されてしまい、実験の実行時に「英国西部」なんていうリージョンはないとエラーになります。正しくは「UK West」ですが、これを設定するためにはポータルを英語表示にする必要がありました*1

f:id:tanaka733:20220118192036p:plain

どのCosmosDBを対象にするかを選びます。

f:id:tanaka733:20220118190102p:plain

これで実験は作成できました。この後、セキュリティーのため、対象となるCosmosDBにこの実験を操作してもよいという許可設定をする必要があります。カオス実験はマネージドIDを利用しているので、CosmosDBのIAMの設定でロールを追加します。「Cosmos DB 演算子」というロールを選びます。Cosmos DB Operatorの訳のようです。

f:id:tanaka733:20220118190416p:plain

マネージドIDを選びます。カオス実験につけた名前でIDが作られています。

f:id:tanaka733:20220118190507p:plain

実験の実行はChaos Studioのページから行います。実行履歴も確認できます。

f:id:tanaka733:20220118233010p:plain

実行すると、実際にフェールオーバーが起きたことを確認できます。

f:id:tanaka733:20220118193006p:plain

10分経過後、フェールバックして元のリージョンに戻ったところまで確認できたのですが、なぜか実験はFailedになっており、詳細メッセージもありません。

f:id:tanaka733:20220118233149p:plain

まだプレビューということもあり、動作が不安定なのでフィードバックしています。次回はエージェント方式の障害を試してみようと思います。

*1:実際に設定されている内容はJSONビューで確認できます。

OpenTelemetry .NETを理解する (1) OpenTelemetryとは

f:id:tanaka733:20220106001746p:plain OpenTelemetry .NETを使って.NETアプリケーションを計測する方法について複数回にわたって紹介してみたいと思います。まず .NET向けの話に行く前に、OpenTelemetryそのものについてかんたんにまとめてみます。

OpenTelemetryの誕生

アプリケーションのパフォーマンスを計測し監視するためには、それまであったプロセスやネットワークの死活監視では不十分でした。Webアプリケーションの例では、1つのHTTPリクエストに対しどのくらいのレスポンスで返しているのか、そこでのボトルネックはコードのどの部分に対応するのか、あるアプリケーションは時間あたりどの程度のリクエストを処理しているのか、といったデータを計測する必要があります。そのようなデータを計測し、監視するためのツールとして、New Relicなどのベンダーが提供するツールが出てきました。New Relicの例で言えば、New Relicの公開が2008年、.NET に対応したのが2012年になっています。

ベンダーが提供するツールは、どんなデータをどのような形式でどのように計測するかといった仕様が多くの場合公開されていません。そのため、たとえ同じデータ、例えば1つのHTTPリクエストに対する平均レスポンス時間、を計測する場合でも、あるツールから別のツールに入れ替えると計測の方法そのものをセットアップしなおす必要がありました。

GitHub上をはじめとしたオープンソースとして公開されるライブラリが増えていく中、ベンダー依存が強いツールは使う場所を選ぶようになってきました。特にライブラリ開発者にとっては、計測ツールへの対応が求められることがあっても、特定の計測ツールに依存したコードを含めてしまうのは避けたいものです。そのような事情もあり、計測ツールのオープンな標準プロジェクトが求められるようになりました。

当初(2018年ごろより)OpenCensusとOpenTracingというオープンなプロジェクトがありましたが、2019年に両者が発展的に合流したのがOpenTelemetryプロジェクトです。

opentelemetry.io

OpenTelemetryとは何なのか

OpenTelemetryのDocsの最初に記載があります。

opentelemetry.io

アプリケーションの状態を知るためのデータをテレメトリーデータ(アプリケーションから離れた場所から収集できるデータ)とし、テレメトリーデータの形式、収集方法、バックエンドへの送信方法をベンダーに依存せず標準化するためのものです。

f:id:tanaka733:20220106001214p:plain

テレメトリーデータは現在のところ、メトリクス、トレース、ログの3種類は想定されていますが、3種類に限定されたわけではありません。今後追加される可能性もあります。

opentelemetry.io

メトリクス、ログ、トレースとはなんだ?という定義については、実際にOpenTelemetryを使いながら説明することにします。今すぐ知りたいという場合は、まずこのページをおすすめします。

www.oreilly.com

また、OpenTelemetryでは対象となるアプリケーションからどのように収集し、どのように送信するか、までを設計しており、送信したあとどのように保存し活用するかについては対象外となります。送信されたテレメトリーデータを保存しUIなどに表示して活用するツールやサービスを「バックエンド」と呼んでいます。OpenTelemetryではどのバックエンドに送信するかを「エクスポーター」と呼ばれるプラグ可能な機能として提供しています。JaegerやPrometheusといったオープンソースなツールからNew Relicのような商用サービスまでさまざまなバックエンドに送信することが可能です。また、これらのツールやサービス側もOpenTelemetry標準の形式でのエクスポーターによるデータ送信が可能になるよう対応を進めています。

OpenTelemetery で計測するために必要なもの

f:id:tanaka733:20220105234322p:plain

計測するためのツールを導入していない状況で新規に導入するケース(図の左下)では、まずアプリケーションのOpenTelemetryの定める形式と方法でテレメトリーデータを収集するための処理を入れる必要があります。多くの場合、ライブラリを参照しコードを追加する必要があるのですが、このことを「Instrumentation(計装=測を実する)」とよんでいます。この部分は、アプリケーションが実装された言語・ランタイムによって最適な方法が異なります。そのためOpenTelemetryプロジェクトでは対応する言語ごとに必要なツールやライブラリを実装しています。また、必要最小限のコードで計装できるようになる自動計装(automatic instrumentation)と、細かい挙動まで実装者が制御できる手動計装(manual instrumentation)が用意されています。いずれかの方法あるいは両方の方法で計装を行います。

opentelemetry.io

計装したことでテレメトリーデータを集められるようになったあとは、バックエンドにデータを送信する必要があり、これを「コレクター(Collector)」と呼んでいます。一番単純な方法としては、アプリケーションで計装したものを直接エクスポーターで送信する仕組みが考えられます。これは図の左下のCollector(Agent方式)が直接バックエンドに送信することを意味します。加えて、アプリケーションで計装したテレメトリーデータをフィルタリングしたり、加工したりすることもできます。アプリケーションプロセスが大量にあるので注目したいデータのみに特化する場合や、ホスト名といった環境情報を付加する場合などです。これは図の中央のCollector(Standalone)に相当し、その中でデータを受信する「レシーバー(receiver)」、加工する「プロセッサー(processor)」、送信するエクスポーターの3つのコンポーネントから構成されます。

opentelemetry.io

計装は言語ごとに用意されていますが、その形式は標準化されているため、コレクターはアプリケーションの言語を問わず利用できます。またJaegarなどの既存のツールを利用している場合、ツールが出力するテレメトリーデータをOpenTelemetry形式に解釈するアダプターとなるレシーバーを介することでOpenTelemetryのコレクターに取り込むことが可能になっています。

f:id:tanaka733:20220106001325p:plain

OpenTelemetryのステータスとOpenTelemetry .NET

OpenTelemetryプロジェクトのステータスはここで公開されています。

opentelemetry.io

メトリクスとトレースの仕様については安定(Stable)となっています。ロギングについてはドラフト状態ですが、メトリクスやトレースと比べてログは既存のログライブラリが多数存在し、いかにそれらとつなぎこむかの設計に時間がかかっているのではないかと想像しています。

また言語ごとに用意されている計装についてはこちらに一覧があります。

github.com

念の為最新の状況は言語ごとのリポジトリで確認しましょう。OpenTelemetry .NETはこちらです。

github.com

これを見ると、TraceとExporterに関しては .NETはかなり対応が進んでいます。Metricsについても対応が進みつつあります

次回以降、実際にOpenTelemetry .NETを使う方法を説明します。なお、バックエンドにはNew Relicを使いますが、その理由はOpenTelemetryネイティブのOpenTelemetry Protocol (OTLP)フォーマットでデータ送信できるという点と、私が一番詳しくしっているバックエンドだからです。

2021年10月にCKAとCKADに同日受験して合格しました

f:id:tanaka733:20211027225813p:plain CKA: Certified Kubernetes AdministratorとCKAD: Certified Kubernetes Application Developerを同じ日に受験して合格しました。

CKA/CKAD(あとCKSも?)は、例えばAzureの資格試験(AZ-303: Microsoft Azure Architect Technologiesなど)と異なり、実際のkubernetes環境を操作して問題として与えられた状態にすることが求められる試験であり、ドキュメントの参照も一定の範囲で可能ということで、異なる準備が必要だったのでまとめてみました。

kubernetes経験と準備期間

OpenShiftのサポートエンジニアとして約3年、そのあとNew Relicに移ってからはNew Relicのkubernetes Integrationのサポートを通して約2年半、扱う機会がありました。ただ、New Relicに移ってからはNew Relic製品全体を担当していたのでkubernetesに触る機会は減ってしまい、せっかくなのでCKA,CKADを通して最新のkubernetes知識をキャッチアップしておこうと思ったのがきっかけです。

試験のバウチャーは約1年前に買ったものの当時は忙しく1年あればいつか暇になるだろうと思っていたら、ますます忙しくなる中失効の連絡が来たのであわてて試験の予約をして、1ヶ月ほど準備 しました。

試験の予約と受験環境

予約は公式サイトで行います。日本の営業時間でも選択肢は多いので、CKAを11時から、CKADを15時からでとりました。

受験環境は受験者が用意する責任があります。机の上にものがなく、まわりにもものがなく、静寂な環境が必要ということで、どう考えても家の中でそんな環境を用意できそうになかったので、会社で契約しているシェアオフィスのソロスペースを使うことにしました。パソコンは会社支給のMacBook Proを使いました。(私用PCはデスクトップだったため)

環境チェックは受験前に行われるのですが、ウェブカメラで部屋の四方と机の上、机の下を写す必要があり、かなり厳格にチェックされます。自分の場合置けたものは、PCとマウス、外部ディスプレイ、ケーブルそしてラベルを剥がしたペットボトルに入れた水です。

また、今回借りたシェアオフィスの部屋の中にコントロールパネル的なものがあり、それを非表示で操作できない状態にする必要がありました。これらの条件の詳細は更新される必要があるので公式サイトでチェックしましょう。

docs.linuxfoundation.org

試験勉強

自分の場合、運のいいことに試験を予約した直後に会社がUdemyと契約し自由に使えるようになりました。そのため、UdemyのCKAとCKADのコースで主に勉強しました。おそらく知識のキャッチアップとしてはこれで十分だと思われます。

一応OpenShiftでそれなりに詳しくkubernetesを知っていたので動画部分を倍速で復習し、Udemyの一貫としてオンラインで提供されるラボ課題を中心に取り組みました。ラボはkodecloudというサービスで提供されており、kodecloud のみを単独で契約することもできるようです。

kodekloud.com

内容的にはkodecloudのラボで十分キャッチアップできるのですが、オンライン端末の操作性は受験環境とは異なります。そこでぜひおすすめしたいのが、受験チケット購入で一緒についてくるkubernetes Exam Simulatorです。

killer.sh

実は購入当初はこれがついてくることに全く気づかず、受験数日前に最終確認するときに気づいてあわてて受けました。My Portalの試験予約ページからアクセスできます。

f:id:tanaka733:20211027214109p:plain

kubernetes Exam Simulatorの最大のメリットは本番とほぼ同じ操作感であることです。例えば、受験環境はWebブラウザ上で提供されるのですが、コンソールは1つしか提供されません*1。kodecloudは気軽に複数コンソールを開けるので注意が必要です。

逆にSimulatorで気をつけないといけないのは、試験につき1セットの問題しか用意されておらず、1回起動すると36時間しかその環境にアクセスできず、1つの試験につき2回までしか環境を起動できないことです*2。なので、これで勉強するのはあまりおすすめできません。例えば、おおよそCKA/CKADに必要な知識は身についているはずだけど...みたいな人は、まず最初にこれでリハーサルしてみるという使い方はできると思います。

また、Simulatorのサイトにも書いていますが、与えられる問題は本番より難しく、量も多いです。自分はドキュメントを検索しながら*3、3時間で全部の問題を解き、7割くらいの得点でした。本番では時終わったあとに十分に見直しをして30分くらい余った状態で試験を終えました。

試験準備

知識のキャッチアップは前項の勉強のところで書きましたが、それ以外にやっておいたほうがよい準備があります。なによりまずImportant Instructionsを熟読しましょう。知らないと受験できなくなることもありますし、試験に役立つ情報もあります。

docs.linuxfoundation.org

本人確認書類

試験直前にウェブカメラごしに見せる必要があります。ローマ字(ラテン文字表記)かつ署名がある本人確認書類だとパスポートが代表的ですが、最近のご時世だと失効した人もいるかもしれません。運転免許証などはローマ字表記がないのでもう1つの書類が必要です。いくつか列挙されていて「Japanese Health Insurance Card」とも書かれていますが、あくまで「有効で、署名があって、ローマ字表記」されている必要があるとのことです。そうでない保険証は使えないと言われました。

ドキュメントのブックマークとドキュメントサイトの構造の確認

CKA/CKADは与えられたkubernetes環境に対して、問題で指示された状態にもっていくタスクが中心です。また、そのときにブラウザで1つだけ追加でタブを開くことができ、以下のサイトとそのサブドメイン(と翻訳が提供されているドメイン)にアクセスできます。

ドキュメントを中心に見ていくことになると思うのですが、注意点は公式サイト上での検索はhttps://kubernetes.io/search/ で提供されるためアクセスが許可されていないということです。また、許可されているサイト内に許可されていないサイトへのリンクが存在しますが、そのリンクをクリックしないことは受験者が自らの責任で求めれています。なので試験中にドキュメントのリンクを踏むことは極力さけたいところです。

そこで、まず受験用にChromeのプロファイルを新規作成した上で、あらかじめ自分が必要なサイトをブックマークにしておきます。自分はSimulatorの問題を解く時に必要だったドキュメントをブックマークにしました。

f:id:tanaka733:20211027215821p:plain

環境設定

CKA & CKAD Environmentのページに利用可能なツールが記載されています。

docs.linuxfoundation.org

まず、kubetlのエイリアスとしてkがbash補完こみで設定されているので、この設定を自分で行う必要はありません。となると、残るはYAML編集です。kubernetes管理にはYAMLが必要不可欠ですが、当然この試験でも大量のYAMLを作成、編集する必要があります。自分は普段はVisual Studio Codeを使うGUI派なのですが試験では使えないので、vimを使うことにしました。が、デフォルト設定だとひどく使いづらいので、以下の.vimrcを設定しました。

set tabstop=2
set shiftwidth=2
set expandtab
set number

この内容も暗記する必要があるので、覚えられる人はもっとたくさん設定してもいいです。また最低限覚えておいた操作は以下の通りです。

操作

  • :wq 保存して終了
  • :w 保存(終了しない)
  • :q! 保存せずに強制終了
  • :set nonumber 行番号非表示(複数行コピーのときに利用)

移動と削除

  • 矢印キー 矢印方向に移動
  • 0 行頭に移動
  • $ 行末に移動
  • :行番号 行番号に移動
  • D カーソル位置から行末まで削除 (ドキュメントから持ってきたYAMLのname: のあとを削除するのに利用)
  • dd カーソル行を行単位で削除(ドキュメントから持ってきたYAMLのいらない部分を削除するのに利用)

使いこなしている人から見ればこの程度???って思われそうですが、このくらいでなんとかなりました。

また1つのコンソールしか開けない代わりにtmuxが利用できますが、普段使っていないので使わないことにしました。実際使えれば便利かなと思う問題はありましたが、大きな問題にはなりませんでした。

試験本番

15分前からアクセスできるようになります。最初に環境チェックが行われて、スムーズにいけば5~10分くらいで完了し試験がスタートします。今回、1回目の受験で部屋のコントトールパネルが問題視されたため、その対応で30分近くかかってから試験がスタートしました。試験時間はスタートしてからカウントされるので影響ないのですが、試験直前に余計な心配ごとが増えるので環境チェックは念入りにしておきましょう。

あと、独り言を含めて話すのは禁止なので、最近のリモートワークで独り言を言いながら仕事をするような人は注意しましょう、

試験問題の言語

試験問題の言語は日本語と英語(あと中国語もあった記憶)から選べます。最初日本語に設定して、翻訳に違和感を感じることなく解いていたのですが、試しに英語に変えたときに意味が全く異なる翻訳になっている部分があることに気づきました。具体的には言及できないのですが正反対といってもよい意味になる誤訳でした。操作したあとに気づき、操作を切り戻す手順がわからずあせったこともあり、以後は問題を英語で表示して解きました。

同日受験

もともと同時受験するつもりはなかったのですが、受験バウチャーの失効まで時間がないので同日受験することにしました。結果的には、試験範囲のかなりが重なっているので全然問題なかったです。

CKADの2021年9月の更新

CKADは2021年9月に内容が更新されています。

training.linuxfoundation.org

内容としては最近よく使われている概念が追加されたということなので、この内容を含んだ教材で勉強すればOKでした。Udemyのコースではすでにこの更新用の章が追加されています。

注意点としては、例えばHelmの項目がありますがHelmのドキュメントは試験中に参照できないので、ある程度のコマンドを覚えておいてコマンドのヘルプとあわせて解く必要があることです。

*1:複数コンソールが必要な場合はtmuxが利用可能

*2:つまり、2回目起動しても1回目と同じ問題が与えられます

*3:本番ではドキュメントの検索は許可されていないことに注意