TechSummit2018 CI29「Azure Monitor の進化とコンテナー監視」聴講

Tech Summit 2018の3日目に参加して、自身の業務に関連するセッションである「Azure Monitor の進化とコンテナー監視」を聴講してきました。
登壇者の原田さんはレドモンド本社でAzureのMonitorサービスを扱っているとのことです。
■セッションレビュー
前段として、Azure Monitorそのものについて説明がありました。
IMG_0544
Azure Monitorの特徴として以下の3つの説明がありました。
・Unified Monitoring
 すべてのメトリクスとログを共通プラットフォームで
・Data Driven Insights
 機械学習を用いた高度な分析と監視
・Workflow Integrations
 DevOps、問題管理、SIEM、ITSMツールとの連携
3つ目の「Workflow Integrations」を見て、自社で活用しているITSMツールなんかと連携できたらおもしろいかも。
IMG_0545
Azure Monitorの統合監視についても1枚絵で解説されていました。
いろいろな場所で見せている絵だとは思いますが、様々なAzureリソースからメトリクスやログを取得して、5つのカテゴリーで活用することを解説していました。
IMG_0546
「Full Stack Visibility in Resource Groups」について紹介がありました。
詳細なリソース監視をするというよりはリソースグループ配下のリソースのヘルスチェックを主にしているように見受けられました。
IMG_0547
「Azure Monitor for VMs」の説明では、「for VMs」とあるように、
VMにスポットをあてた機能になっております。
画面からですが、かなり詳細に監視ができてるような印象をうけました。
ここまでは前段でしたが、
これ以降は本題のコンテナ監視についての説明を始めていました。
IMG_0551
最初は「フルスタック監視」について、
インフラ監視とアプリケーション監視ってできてるけどコンテナの監視は?の投げかけがありました。
コンテナ監視が難しい理由について以下4つがあります。
・作成・起動・停止のいずれも非常に短時間
・統合環境による「うるさい隣人」問題
・コンテナのイメージ、状態、稼働場所のトラッキングが難しい
・1か所でコンテナ環境を監視するツールが内蔵されていない
コンテナ監視の難しさとは反対に、コンテナ監視の需要は高いといろいろなお客様から要望をいただいているようです。
・アプリの障害がクラスターの問題なのかを見極めたい
・問題提起をしてくれる監視ツールが欲しい
・クラスター内をドリルダウンができ、フィルターかけたい
・デベロッパーのkubectlなどクラスターへのアクセスを制限したい
・監視システムの管理に人件費や手間をかけたくない
・Azure上でkubernetesを使っているなら、Azureの監視ツールを使いたい
IMG_0555
コンテナを監視したいという要望から、「Azure Monitor for Containers(プレビュー)」が誕生しました。
これは先ほどの「Azure Monitor for VMs」と同様に、Azure Monitorの1機能としてあります。
視覚的にわかりやすく、一目で障害の有無を確認できて、DevOpsとも連携できるということで
利用できるものにはなっているという印象を受けました。kubernetesイベントとContainer logも解析できるのも良い点だと思います。
IMG_0558
最後にAzure Monitorのロードマップを出していましたが、
「Azure Monitor for Containers」を来年の早い段階でGAしたい話と、
「Azure Monitor for Containers」を使ってみて、フィードバックをくださいと付け加えていました。
■Ask the Speaker
 セッション終了後、原田さんにAzure Monitor for ContainersなどのAPI提供について聞いてみましたが、あまり考えてないということ。
マイクロソフトの考えとしては、zabbixなどのサードパーティ監視サービスを使うのではなく「Azure Monitor」
サービスを利用しほしいと話されていました。
サードパーティの監視サービスは管理が大変なので、それを解消できるような
各Azureサービスのに寄り添ったMonitorサービスを出していきたいとのことです。
「Azure Monitor for WebApps」とかがでる日も遠くないかもしれないですね

Tech Summit 参加レポート(CI17)(VDI環境最新化のシナリオ – MicrosoftのVDI戦略)

〇はじめに

クラウドソリューションエンジニアの藤井です。
Tech Summit 2018で受講したセッション「VDI環境最新化のシナリオ – MicrosoftのVDI戦略」について、ご紹介します。

〇VDIとは何か

そもそもVDI(仮想デスクトップ方式)とは何かを理解する上で、SBC(ターミナルサービス方式)も関連して解説します。

・VDI(仮想デスクトップ方式)

ユーザーごとに独立して構築された仮想OS環境に、リモートでログオンして利用します。OSはクライアントOSが利用されます。仮想OS環境のローカルドライブにファイルを保存することや、アプリケーションをインストールすることもできるため、同じユーザーが継続的に利用する場合に適しています。CPUやメモリなどのリソースを占有で割り当てるため、スペック要件の高いアプリケーションを利用する場合に適しています。

・SBC(ターミナルサービス方式)

複数のユーザーが同じOS環境を共有して利用します。OSはサーバーOSが利用されます。CPUやメモリなどのリソースを共有することで効率よく利用したい場合や、ホストOSにアプリケーションをインストールすることで、共通のアプリケーションを利用したい場合に適しています。

画像1

〇クラウド上のVDIが今、注目される背景

2017年8月のライセンス規約改定により、Windows のクライアントOSの仮想環境をパブリッククラウド環境(複数のユーザー企業がホストOSをシェアするマルチテナント環境)で利用することが解禁されたことが、注目されている背景です。

従来はサーバーOSを利用する他に選択肢が無いため、SBC方式を選択するか、もしVDI方式にこだわるのであれば、サーバーOSをカスタマイズしてクライアントOSのデスクトップエクスペリエンスに近づける必要がありました。解禁前の2014年時点では、AWSのWorkspacesでは、デスクトップエクスペリエンスをWindows 7のようにカスタマイズしたWindows Server 2008R2(Datacenter Edition)が利用されていました。

画像2

クラウド環境を利用することで、ハードウェアやネットワークの管理から解放されるメリットを享受できる点は、サーバー環境をクラウドに移行する場合と同様です。

 

画像3

〇Azure上でVDI利用について

Azure上でVDI環境を構築する場合は、以下の選択肢から検討します。

(1)Windows Virtual Desktop(※)
(2)VMware Horizon Cloud on Microsoft Azure
(3)Citrix Cloud on Microsoft Azure
※2018年11月27日現在、プレビュー段階

画像4

基本的な機能のみ利用する場合はWindows Virtual Desktopを選択し、より高度な管理機能などを利用したい場合はVMwareやCitrixの製品を選択することが想定されています。

画像5

Azure上でVDIを利用するメリットはOffice 365とAzreuがバックボーで接続されており、例えばOne Driveで大容量のファイルを操作する場合でも快適に利用できます。

画像6

さらにWindows Virtual Desktopを選択する場合、Office 365のライセンスで使用できます。特に端末側が通常のPCである場合、Windows OSのライセンスを二重で購入することを回避できます。

画像7

Tech Summit 参加レポート(AD09)(Linuxユーザが扱うAzure Resource Manager Templateの活用方法)

〇はじめに

クラウドソリューションエンジニアの藤井です。
Tech Summit 2018で受講したセッション「Linuxユーザが扱うAzure Resource Manager Templateの活用方法」について、ご紹介します。
セッション内の様々なトピックスから抜粋してご紹介し、Azure Resource Manager Template(以下、ARM Template)を、藤井が過去の案件で利用した時の経験も補足いたします。

〇ARM Templateとは何か

ARM TemplateとはAzure Resource Manager(ARM)モデル(※)として、デプロイされた各リソースの情報を、json形式でテンプレート化したものです。
各リソースの設定だけでなく、リソース同士の依存関係もテンプレートの情報に含まれています。
既存の環境の構成をバックアップできることに加えて、開発用や本番用などとして同じ構成の環境を、繰り返し複製することができます。

※Micorosoft Azureで提供されている各種サービスは、大別して2種類に分かれます。
2010年にAzureのサービスが開始された時から提供されているAzure Service  Manager(ASM)モデルという区分と、2015年から提供が開始されたAzure Resource Manager(ARM)モデルという区分が存在します。

〇セッション内容の紹介

トピックス①パラメータファイルの分割について

ARM Templateでは「本体ファイル」とは別の「パラメータファイル」として、一部の値を記載し「本体ファイル」に読み込ませることができます。
社内共通で必ず設定する値を「本体ファイル」に記載し、利用者ごとに変更するような値を「パラメーター」ファイルに記載することで、各利用者が「本体ファイル」の値を不用意に
変更しないようにすることができます。

topics1

トピックス②デプロイは40分でタイムアウトし、ロールバックはされない

構築が一部のリソースのみ成功した場合、成功したリソースはリソースグループに残される。一部が失敗した後に、同じリソースグループへ再実行して全て成功した場合、作成済みのリソースはスキップされ、未作成のリソースのみ追加されます。
topics2.JPG

トピックス③リソースの依存関係について

複数のリソースを作成する場合に、作成する順番をARM Templateファイル内で”dependson”として制御する必要がある場合があります。何も指定が無い場合、リソースは常に同時に作成されます。例えば、仮想マシンは仮想ネットワークに対して登録されるので、仮想ネットワークが先に作成されるように制御します。
topics3.JPG

トピックス④ループ処理を利用する

「ループ処理」の機能を利用することで、「Code as a Infrastructure」としてプログラムのように処理を組むこともできます。例えば、クラスター環境で仮想マシンを大量に構築するときに有用です。同じ設定の仮想マシンを「ループ処理」で構築するプログラムを組むことで、作成する仮想マシンの台数を「ループ処理」の実行回数として柔軟に増減させることができます。
topics4.JPG

トピックス⑤JSONファイルの編集

JSONファイルを直接に編集するのが大変なケースも多いので、linuxユーザーにはなじみのあるYAML形式で作成して、変換する方法方も公開されています。
https://github.com/TeamYARM/YARM-CLI
topics5

 

〇藤井の経験則から補足

トピックス①パラメータファイルの分割について

セッション内で紹介されているケースとは逆に、利用者数が少なかったり、
特定のチームに限定される場合は、「パラメーターファイル」を使用せず、
全て「本体ファイル」で完結させた方が、簡便です。

トピックス②デプロイは40分でタイムアウトし、ロールバックはされない

リソースの種類数が多いときは、種類別に分割してARM Templateを設計することがお勧めです。修正を加えてテストするときに、対象の範囲を絞ることができます。

トピックス③リソースの依存関係について

設計時の肝要になるポイントです。
作成されるリソースの順序関係を指定した場合、前の順番のリソースの作成が完了してから、次のリソースの作成が開始されるため、全体の完了時間を左右します。
不要な設定をすると、完了に時間がかかります。

トピックス④ループ処理を利用する

ARM Templateの利用するメリットが最も発揮される機能です。藤井が対応したケースでは、100台以上のサーバーを同一のマスターイメージから大量に作成し、コンピューター名やIPアドレスなどを連番で割り振るように実装しました。ループ処理の回数などの実行条件を、利用することで、仮想マシンのリソース名を「1号機、2号機・・・」と連番で割り振るといったこともできます。

トピックス⑤JSONファイルの編集

セッションで紹介のあった方法以外に、エディターから直に編集するときは、Visual Studio Codeを利用すると、インテリセンスによる入力が利用できとても便利です。

〇その他

セッション内で説明のあったトピックス以外に捕捉すると、SSH接続にパスワードを使うパターンだけでなく、認証鍵を使うパターンでも同様に構築ができた実績があります。

TechSummit2018 DA08「性能問題を起こしにくい信頼されるクラウドRDBのつくりかた」を聞いて 後編

こんにちは、南條です。

前回の投稿からtechsummit2018のセッション、DA08「性能問題を起こしにくい信頼されるクラウドRDBのつくりかた」のレポートを前後編に分けて行ってきました。
前編では、クラウドRDBの性能低下を防ぐために、ストレージシステム構成時にどのようなことができるかについてまとめてきました。
後編では、ストレージシステムを動かし始めてから運用中に起きる性能低下に対して、どのようなことができるかについてまとめていきたいと思います。 続きを読む

Web APIの作成と実行

こんにちは、本日の記事を担当します中田です。
6月に入ってから気圧の急な変化も多く頭痛に悩まされていますが、みなさんは大丈夫ですか?これから梅雨に入りさらにひどくなると思うので、今年も頭痛薬は手放せそうにはないです。

さて本日は最近勉強したWeb APIの作り方と簡単にブラウザ上での実行の仕方を記事にしたいと思います。 続きを読む

Chat Bot(チャットボット)について

本日の更新を担当します中村です。
私事ですが、先輩社員の皆様と一緒に高尾山に登ってきました。
登山などは初めての経験だったので、アウトドア用品店に行き、必要なウェアなどをすべて購入しました。
登山中は辛い時もありましたが、頂上からの景色が忘れられないので今度違う山にも登ろうと思います。 続きを読む

C#7の一部新機能について

こんにちは、本日の記事を担当します中田です。
最近とても暑い日も続き、本日東京では30℃を超える場所もあるそうですが皆さん元気に過ごせていますでしょうか。
私は暑いのが苦手ということもあり梅雨前だというのに既にバテ気味でこの夏乗り越せるかこの時期から心配です。

今回は、de:code2017でC#7の新機能に関するセッションを聴いてきたので、それらの機能の一部を自分でさわった感覚も交えながら紹介したいと思います。

まだすべての機能をさわりきれてないので2つの機能だけの紹介となります。

続きを読む