kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure始める人向けに見てほしい資料など

Azureにはいろんなサービスがあるので未経験の人が使いはじめるのはなかなか難しくなってきました。特に初学者向けの研修といえばVM作るあたりから始めるのは仕方ないものの、それだけで本番作るとちょっと困る。そして最近新しく始める人からよく「これだけやっておけばいいよ」というものない?という相談を受けることが多くなりました。どんな要素を押さえておかないといけないかなぁ?ということでつらつらとまとめてみます。忘れているものとかあれば教えてください。

クラウドを使う前に目を通してほしいもの

azure.microsoft.com

クラウド移行するためのフレームワークです。技術的な話だけではなく、組織やセキュリティの定義を決めましょうというような話をフレームワークとしてまとめられています。

docs.microsoft.com

クラウドは日進月歩です。日々ベストプラクティスは更新されています。そういう視点でコスト、セキュリティ、信頼性、運用容易性、パフォーマンス効率といった観点でどうやって運用するつもりであるかというチェックリストです。

Microsoft Learn

docs.microsoft.com

使う技術を選んだらMicrosoft Learnで基本的な学習をお勧めします。新しく入ったメンバーに技術要素を学んでもらうためにもお勧めです。個人用Microsoftアカウントを使えばどこまで学習したか記録してくれて、無料で実際のAzure環境を使った演習ができる内容もあります。

Azure Service Healthの通知を受け取る

azure.microsoft.com

Azureも計画的なメンテナンス、重大な性能低下、非互換を伴う仕様変更といったことがちょこちょこ起きます。そういった情報を通知してくれます。サブスクリプションごとに設定しなければなりません。モバイルアプリへの通知、Webhookを使用して外部のシステムに通知する、メール通知するといったことも可能です。

Azure AD

docs.microsoft.com

AzureのID管理はAzure ADです。とりあえずこれを理解しないと始まりません。組織の既存のIDシングルサインオンをするもよし、独自のIDにしてもいいですが…めんどくさいです。ユーザーだけではなくEndpoint ManagerやMicrosoft 365 Defenderと連携することでデバイスの制御もできるようになります。例えばポータルにアクセスするにはAzure ADに参加しているデバイスで最新のパッチが適用されていなければならないというポリシーの設定も可能です。

ID管理

Azure ADは一定以下のオブジェクト(ユーザー、グループなど)であれば無料で使えますが、一定以上のセキュリティ機能を使おうとすると有償ライセンスを検討します。

docs.microsoft.com

  • ポータルにアクセスして何らかの更新権限がある人:Azure AD Premium P1
  • 何とかの管理者権限がある人:Azure AD Premium P2

Azure AD PremiumはEnterprise Mobilityにも付属するライセンスなので通常組織内のデバイスセキュリティを考えると別途用意するまでもなく「用意するもの」かなと思います。気にするのは組織外から招待した協力会社のアカウントでしょうね。

Azure ADのライセンスはテナントごとなので、例えばAzureアプリケーションをセキュリティのため別テナントにしよう!という考えでテナントわけてしまうと、新規テナント用にAzure AD Premiumライセンスが別途かかりますので気を付けてください。

docs.microsoft.com

多要素認証MFAは新しく作られたテナントなら初期設定されているので、明示的に無効にしない限りアプリ通知は使えるので、スマートフォンもしくは類するデバイスを用意しましょう。

セキュリティの指標としてIDセキュリティ スコアという機能が提供されています。こちらを見て、継続的に改善してください。

権限の管理

Azure ADのグループやセキュリティのほかにRBACの理解が必要です。例えば「VMのモニタリングはできるが起動・停止はできない」という権限を作りたい場合、RBACを使わなくてはなりません。適当にやるとドはまりしてひどいことになるので、注意してください。Azure ADでグループを作って、そのグループに対して割り当てるという形になるでしょうね。

RBACは出来合いの組み込みロールがありますので、そこから不要なものを削っていく方向で作るのがおすすめです。

特権ユーザーの管理

Azure ADの全体管理者などの特権ユーザーはAzure AD Premium P2を割り当てて、Azure AD Privileged Identity Managementで使用時の特権昇格するようにしましょう。

docs.microsoft.com

ただ、ドメインアカウントに割り当てたアカウントのみだとドメインが乗っ取られてしまった場合どうにもならなくなるので、onmicrosoft.comドメインのアカウントを緊急アカウントとして割り当てる必要があります。

アプリケーション用ID

(2022/7/25追記)

昔は特定のIDを作ってそれをアプリケーション専用に割り当てるなんてことをやっていた人も多かったと思います。典型的な例で言えばSQL DatabaseのSQL認証ですね。そういうIDを作ってしまうと総当たりでやられることがあります。

docs.microsoft.com

マネージドIDの使用を検討しましょう。こちらもプライベートリンクリソース同様にプレビューやGA直後はサポートしていないサービスがあったりするので、使えるかどうか確認してからということになります。

docs.microsoft.com

ネットワークはどうしても理解しておかないといけないものですね。とりあえずPrivate EndpointPrivate Linkは理解しておかないと閉域網作れません。パブリックなサービスだからといっても、データベースがインターネットからアクセス可能にしておくということはないですしね。

データを格納するPaaSを選ぶ場合プライベート リンクリソースに載っているものから選びましょう。プレビュー時点ではサポートしていないものも多いですし、そもそも高いSKUじゃないとプライベート リンクをサポートしないものも多いので、課金にも注意です。

Azure Monitor

docs.microsoft.com

マネージド管理するならまずはAzure Monitorから。Elasticソリューションに慣れた人にはElastic on Azureなんてものもありますね。

docs.microsoft.com

診断や監視するのはいいですが、Azure Monitorの料金は読みづらいもののひとつです。サンプリングして料金を計測していくしかないですね😅。

docs.microsoft.com

docs.microsoft.com

docs.microsoft.com

Log Analyticsという名前も若干悪いと思っていますが、中身はデータウェアハウスなのでほっとくと馬鹿みたいにコストが上がります。要件上の理由で保存が必要なら定期的にエクスポートしましょう。

docs.microsoft.com

Defender for Cloud

docs.microsoft.com

とりあえずStandardを購入してサブスクリプション全体に適用してしまいましょう(暴言)。経験の少ない人でも設定ミスがだいぶ減らせます。例えば既定でSQL DatabaseはAzure内のどこからでもアクセスできます。そういう設定を検出してくれます。セキュアスコアを順次改善しましょう。

docs.microsoft.com

Azure Policy または Azure Dev Test Labs

docs.microsoft.com

「xxをやってはいけない」といわれても覚えていられないし、やってしまうことはあります。そういうことをできなくするのがAzure Policy。検証向けのサブスクリプションで評価して、本番向けのサブスクリプションに適用していくのがいいのでしょうね。

ただ、純粋な開発環境でそこまで不要で例えば「東日本にこのサイズのVMまでしか作ったらだめですよ」という制限したいだけならAzure Dev Test Labsでも用が済むかもしれませんね。SLAがない代わりに安いですし。

Azure Cost Managementで支出を管理する

(2022/7/25追記)
docs.microsoft.com

コスト意識も重要です。AzureにはCost Managementという機能もあるので、詳細な分析をしてみてください。ポータル触らせたくないけどコストは見せたいという場合、Power BIとの連携もできます。

Azureで自動処理を行うためのPaaSは何を選ぶ?

今自分が得意だからということもあるのですが、Azure Pipelinesを使って簡単なデータ流し込み処理をしています。ふと思ったのですが、ほかにもこの手の自動化で使えるPaaSがあってどういうときに使えばいいのかなと思って考えてみました。

Azure Automation

docs.microsoft.com

  • Azure インフラストラクチャの構成管理、簡単な自動化処理
  • Python, PowerShellスクリプト 5.x / 7.1(Preview)とAzモジュールで書いたスクリプトを指定した時間、指定した条件で実行する
  • 500分の無償枠あり
  • Hybrid Workerでオンプレミスも管理可能(クラウドと値段が違うのに注意)
  • ソースコードはGitHub / Azure Reposで管理&デプロイ可能
  • incoming Webhookでの実行も可能

日本ではJP1などのジョブ管理ソフトを使って「指定した時間にこのVMを再起動させる」とか「この処理を実行する」みたいなことをよくやっていますね。Azure Automationの場合、単発処理は楽ですが、「Aというジョブを実行した後にBというジョブを実行するけど、この条件の時はCというジョブを実行する」みたいな複雑な処理だとできないことはないけど、ちょっと辛いかも。特に業務的なカレンダーがあってそれを参照しながら動くとかね。あと、一応グラフィカルPowerShellワークフローというものはあるのですが、ランタイムが現在5.1のみなので、ちょっと辛い。

Runbookを使って、定期的に短時間で済むけど、手順書見ながらやらなくてはならないような処理はまずこれ検討したらいいように思います。

Azure Pipelines / GitHub Actions

よく使っています(笑)。Microsoftが運用するHosted Agentと自分で運用するself-hostedがあります。私が使うのはだいたいself-hostedのVMSSエージェントです。

self-hostedを使う理由ですがこの辺ですね。特に1番目と3番目が大きい理由です。

  • Microsoft-hostedは60分でジョブが打ち切られる
  • 仮想マシンがDS2くらいなので、2 vCore / 8GB RAMではつらいことがたまにある
  • 閉域網内で処理したい

処理はShell Script / PowerShell / 任意のプログラムなんでもいいので便利です。YAMLの試行錯誤がちょっと辛いかな。Azure Automationがローカルでテストしたスクリプトがほぼそのまま動くのと違って、参照情報が変わることが多いのがつらいかもしれないですね。

こちらも無償枠はありますが、申請式です。

docs.microsoft.com

1-2営業日で返事は来るはずです。

Microsoft Hosted agentの場合は定期的にイメージが変わるので、インストールされているソフトの変更には注意してください。node.jsとかPythonとかですね。self-hostedを使う場合、VMSSエージェントの利用が前提になると思いますが、VMイメージ作成を自動化していないと厳しいでしょうね。私は毎月OSパッチリリースのタイミングでAzure Compute Galleryに入れるイメージを作り直しています。

Azure Functions(のTimer Trigger)

docs.microsoft.com

この辺に注意ということで。実行時間を無制限にするにはPremium以上のプランにするか、Consumption planの場合は別途Container AppやAzure Batchなどにリクエストだけ投げて結果は別の方法で受け取るといった処理にする必要があるでしょうか。

こちらもAzure Automationと同様に複雑な条件分岐を実装することはできるけどコードでやるのはどうかな?というところです。Functionsなので、CI/CDもサポートされていますね。

(追記)
Logic Appsもコネクターで用意されている範囲であれば可能ですね。もちろんAzure Functionsと連携もできますが、それなら最初からFunctionsでいいじゃないかとも思います。

Azure WebJobs(2022/6/5追記)

docs.microsoft.com

すっかり忘れていましたが、Azure WebJobsもありますね。現状ほとんどFunctionsになると思いますが。

じゃあ何選ぶ?

ものによるけど、やはりAzure Automationでできるかどうか考えるかなぁ。Functionsは正直あまり考えない。Pipelinesは並列度が多くなると課金が比例するのと、イメージ作るのが面倒になりますね。

github.com

GitHub Actions / Azure Pipelinesと同じイメージを作るこのレポジトリをforkして、だいぶそぎ落としたカスタマイズ版を使っていますが、それでも1時間ちょっとはかかりますので。

ほかにこんな方法でやっているよ!とかあれば教えてください。

Azure Pipelinesから Azure Load Testingの負荷テストを実施する

f:id:kkamegawa:20211211130329p:plain この記事はAzure DevOpsアドベントカレンダー12日目の記事です。

qiita.com

Azure Load Testingについて

先日、Azure Load Testingという新しいサービスがプレビュー公開されました。はっきり言ってしまえばJMeterのマネージドサービスです。

azure.microsoft.com

あれ、Azure DevOpsにもLoad Testがあったよね?と思われるかもしれませんが、ありました。そして2020/3/31にディスコンになりました。

azure.microsoft.com

Visual Studioと統合されていて、VSのロードテスト機能からも使えて便利だったのですが引退してしまい、ちょっと困っていました。何回か紹介したことがあります。

kkamegawa.hatenablog.jp

kkamegawa.hatenablog.jp

今ではほかのマネージドサービスを使うか、pnopさんが出しているカスタムイメージ使うか、というくらいでしたが、新しいオプションとして選択できそうです。

www.pnop.co.jp

ちょっと試してみましょう。注意事項としてjmxファイルの内容(サンプラー名やコントローラー名といったメタデータ)は英語で書きましょう。最初日本語で書いていてLoad TestがAcceptedのままずーっと動かなくて悩みました。もしかして、と思って英語に変えたらあっさり動きました。JmeterのUIを日本語にすると自動的に日本語のメタデータが入っていしまうので、英語で使うことをお勧めします。

そういえばAzure DevOps Load Testのときも同じことで悩んでいたような…。jmeterのインストールはchocolateyやmacOSの場合はHomeBrewでできるので省略(いまだにJRE 8をペアで入れさせられるのには閉口しますが…)。そういえば、macOSでjmeterのファイル保存できないのLook & Feelを変えないといけないって誰が気付くんだ。

ポータルから作成する

f:id:kkamegawa:20211208060542p:plain

ポータルから作成します。

f:id:kkamegawa:20211208060549p:plain

サブスクリプション、名前、リージョンを設定します。今のところ限られたリージョンだけですが、米国中南部を選んでみます。Load Testingの枠としてはこれだけなのですぐ作成すればOKです。

ポータルからテストを実行する

Test Plan, Parameter(実行時パラメータ), テスト合格基準、モニタリングなどポータルから設定します。

f:id:kkamegawa:20211208060622p:plain

テスト名は任意。Run after creationにチェックがあるとすぐに実行されます。

f:id:kkamegawa:20211208060626p:plain

ここで作っておいたjmxファイルをアップロードします。くれぐれもリスナー名やクライアント名に日本語を使わないようにしましょう(重要なことなので繰り返し)。

f:id:kkamegawa:20211208060630p:plain

実行時パラメータがあれば指定します。

f:id:kkamegawa:20211208060634p:plain

実行エンジン数を指定します。4を指定すれば1000スレッドまでかけられるようですね。jmxでは250スレッドまでなので、それをいくつの実行エンジンでスケールするかということのようです。

f:id:kkamegawa:20211208060650p:plain

ここでエラー基準を決めます。注意事項としてWeb Appsのお安い(FとかDとか)インスタンスではウォームアップの時間が必要になるので、ここにあるように応答時間(Response Time)に100msなどの短い時間を指定していると初回実行が間に合わなくて失敗します。

f:id:kkamegawa:20211208060642p:plain

モニタリングするリソースを選択します。

f:id:kkamegawa:20211208060654p:plain

作成したら即実行が始まります。

f:id:kkamegawa:20211208060658p:plain

f:id:kkamegawa:20211208060701p:plain

こんな感じで結果が見えます。failedになっているのは上で書いた通り実験用の環境でWeb Appsのウォームアップが間に合ってないからです😅。実行には気を付けて。さて、CI/CDで実行するための準備をします。

CI/CDのためにロール割り当てを設定する

Azure Load Testingはプレビューだからか作っただけではAzure Pipelinesから呼び出せません。ロール割り当てをします。

f:id:kkamegawa:20211208060555p:plain

いつものようにService Connectionを作成して、Azure Load Testingのリソースグループを割り当てます。Manage Service Principalをクリックしてアプリケーションを表示して、アプリケーション表示名をコピペします。

f:id:kkamegawa:20211208060607p:plain

Load Testing Contributorにアプリ追加します。

f:id:kkamegawa:20211208060617p:plain

こんな感じで割り当て終わりです。

Azure Pipelinesから呼び出す。

marketplace.visualstudio.com

Marketplaceからタスクを追加します。実行する前に以下の二つをどこかのレポジトリにコミットしておかなくてはなりません。

  1. Azure Load Testingを実行するテストケースを記述したYAMLファイル
  2. JMeterのjmxファイル

アプリケーション外部のレポジトリでもいいですし、一緒でもいいでしょう。ただし、「Webアプリケーションはこういう基準で動かなければならない」ということが品質のルールで決められているとしたらレビューする人たちにも参照可能な外部レポジトリを用意しておくのがいいかもしれませんね。

jmxファイルも同様です。

サンプルのAzure Load Testing実行するためのYAMLです。

version: v0.1
testName: SampleTest
testPlan: sample1.jmx
description: 'Load test website home page'
engineInstances: 1
failureCriteria:
  - avg(response_time_ms) > 300
  - percentage(error) > 50

CSVでパラメータ指定も可能です。testPlanにはこのYAMLから参照可能なパスで指定してください。ここでは同じフォルダーにダウンロードしているのでパス指定はありません。

f:id:kkamegawa:20211209173720p:plain

YAMLで実行するステージを切り出すとこんな感じですね。

  - stage:
    dependsOn: Deploy
    condition: succeeded()
    jobs:
    - job: LoadTest
      pool:
        vmImage: 'Ubuntu-latest'
      steps:
        - task: DownloadBuildArtifacts@0
          displayName: 'Download Artifact'
          inputs:
            buildType: 'current'
            downloadType: 'single'
            artifactName: 'myWebsiteName'
            downloadPath: '$(System.ArtifactsDirectory)'
        - task: AzureLoadTest@1
          inputs:
            azureSubscription: '{サービス接続名}'
            loadTestConfigFile: '$(System.ArtifactsDirectory)/myWebsiteName/azure-load-testing.yml'
            resourceGroup: '{リソースグループ名}'
            loadTestResource: '{ロードテスト名}'
        - publish: $(System.DefaultWorkingDirectory)/loadTest
          artifact: results

ここでは明示的に別ステージにしています。通常デプロイが成功したらこの手のテストを実行するので、dependsOnにデプロイ用のステージを指定して、conditionsucceeded()を指定しています。

なぜDownloadBuildArtifactsタスクがあるのかと思うかもしれませんが、ステージが異なるとartifactの参照ができません。明示的にダウンロードしてくる必要があります。なので、YAMLとjmxはCopyFilesタスクでBuild.ArtifactStagingDirectoryにコピーして、PublishBuildArtifactsタスクで発行しなくてはなりません。デプロイされるアプリケーションとは別のartifactsにしておく方が望ましいかもしれませんし、同じテストを繰り返すという意味では一緒のほうがいいかもしれません。ここはお好みですかね。

最後のpublish: $(System.DefaultWorkingDirectory)/loadTestでテスト結果を発行しています。

f:id:kkamegawa:20211209173724p:plain

成功するとこんな感じですね。ログにhttpの応答時間や、View the load test run in progress atでAzureポータルのリンクが出ているのでワンクリックで結果が見えます。

f:id:kkamegawa:20211209173727p:plain

ポータルと同じようにYAMLに設定したfailureCriteriaが満たせない場合、ビルドが失敗したと表示されます。

f:id:kkamegawa:20211209173731p:plain

Azureポータルでもこんな風に失敗となります。

注意事項

  • Public InternetにあるURLに対して実施するものなので、閉域にあるサービスに対してはかけられません。JMeterのカスタムイメージ使いましょう。
  • jmxは英語で書きましょう
  • 実施可能なデータセンターの場所が限られていますので、応答時間気にするサービスで日本になくてはならないものだとちょっと注意が必要です。
  • YAMLのステージ分割は必須になる
  • YAMLとjmxをレポジトリに入れて、artifactsとしておくのを忘れずに

Azure DevOpsとセキュリティ&コンプライアンスのお話をしてきました

オルターブースさんからお話をいただいて、Azure DevOpsとコンプライアンスとセキュリティというお話をさせていただきました。

alterbooth.connpass.com

資料はこちらです。最初Azure Policy設定してもエラーになるのになんで?って悩みまくっていたのですが、聞いたらリソースプロバイダーがないからだといわれました。Azureポータルからは設定できるのに…。Releaseで設定したらそのついでにリソースプロバイダーも設定してほしいものです(わがまま)。

自分もこの辺知識として知ってはいたのですが、実際にどういう挙動なのかいまいち理解していないところもあったので、いい勉強になりました。今回参加できなかった方向けに再演とかデモとかやったほうがいいかな?よければコメントなり、Twitterなどでコメントください。