“The way to use Azure Resource Manager Template for Linux Users”

〇Summary 

My name is Ren Fujii, and I am a cloud solution engineer. This article introduces one of the sessions at Microsoft Tech Summit 2018 that I attended, titled, “The way to use Azure Resource Manager Template for Linux Users”. 

 

I will select some of the various topics of the session to introduce and add my opinion from my experiences of my past project where I used Azure Resource Manager Template (ARM Template) 

 

〇What is an ARM Template?  

 

ARM Template is templatized information about resources in the format of JSON, each of which is deployed on Azure Resource Manager (ARM)Model. 

The information of the templates includes dependencies among resources as well as the settings of each resource. 

Not only backing up the structure of existing environments, it lets you duplicate the environments with the same structure repeatedly for other tasks such as “Development” and “Production”. 

 

Note: Services provided on Azure are categorized into two types. The one is the Azure Service Manager (ASM) model, which has been provided since 2010 when Microsoft started Azure. The other is the Azure Resource Manager (ARM) model, which has been provided since 2015. 

〇Introducing the Session 

Topic 1: Separating Parameter files 

In ARM Template, some of the values can be input as a “Parameter File”, separated from the “Main Template File” and referred to it. For example, separating the files like below will prevents their users from unintentionally changing the values of “Main Template File”. 

“Main Template File” has values of mandatory items which are commonly set in a company, and “Parameter File” has values of other items which  depend on each user. 

topics1

Topic 2: Deployment will be timed out in 40 minutes and roll back won’t be executed 

When a deployment succeeds on only a part of resources, its deployed resources will be left in the Resource Group. The deployed resources will be skipped, and only the incomplete resources will be added when another deployment is executed successfully.  

topics2

Topic 3: Dependencies among resources 

Creating multi resources sometimes requires controlling the order of creating them in ARM Template as “dependson”. If nothing is specified in “dependson”, all resources will be always created simultaneously. For example, since virtual machines belong to virtual networks, the virtual networks should be created first. 

topics3

Topic 4: Using Loop processing 

With the function of “Loop processing”, ARM Template can be programmed to be like “Code as an Infrastructure”. For example, it is useful for creating huge number of virtual machines in a clustered environment. Through virtual machines with the same settings are programmed with “Loop processing”, the number of the created virtual machines can be flexibly adjusted as the executed counter of “Loop processing”

topics4

Topic 5: Editing JSON files 

The file can be created in the YAML format, which is popular in Linux users, and be converted into JSON. Since it is often hard to edit JSON files directly.

topics5

〇Additional recommendation from my experiences 

  Topic 1: Separating Parameter files 

In the situations where the number of users is small or the users are limited to a particular team, it is easier to complete everything in “Main Template File” without using “Parameter File”. 

The situations are opposite of the one explained in the session 

 

 Topic 2: Deployment will be timed out in 40 minutes and roll back won’t be executed 

It is recommended to design ARM Template by separating resource types, if the number of created resource types is large. When the separated ARM Templates are changed and tested, the scope of the test will be limited. 

 

 Topic 3: Dependencies among resources 

That is the most important point of designing ARM Template. 

The length of the time until each deployment finishes depends on this point. 

If the order of the created resources is specified, then the next resource will start to be created after the previous one is finished. 

 

Topic 4: Using Loop processing 

This function can bring about the greatest merit in using ARM Template 

In my previous project, I have designed my ARM Template to create more than 100 servers from the same master image and to give the servers such computer names and private IP addresses as they are combined with the serial number. The resource names of virtual machines can also be combined with serial number such as “VM_No1″,”VM_No2”, etc., through using its executing conditions such as the executed counter of “Loop processing” 

 

Topic 5: Editing JSON files 

In addition to the way introduced in the session, Visual Studio Code is also very convenient to edit ARM Template directly since IntelliSense is available. 

 

〇Others 

In addition to the topics explained in the session, I have succeeded in creating virtual machines with an SSH Key as well as with a password for SSH log-in. 

Tech Summit 2018参加レポート(DA52) ビッグデータソリューション構築のための適切な技術選択とは?

こんにちは。Cloud Solutions Engineerの花野です。

前回の投稿に引き続いて、Tech Summit2018の参加セッションのご紹介をさせていただきます。

DA52 ビッグデータソリューション構築のための適切な技術選択とは?

DSC_0287

こちらは「セッション」ではなく、「チョークトーク」でした。チョークトークとは講義形式で進む通常のセッションとは異なり、演者と聴衆がインタラクティブにディスカッションをしながら進む形式の一コマです。会場の設えも工夫されており、演者の方と参加者との距離が近くて新鮮でした。

開始時間ギリギリに行ったらほぼ満席で、なんとか端っこに潜り込ませてもらいました。

そんな大人気のチョークトークのテーマは、「ビックデータのソリューションを構築するにあたってのベストプラクティスやアンチパターンを議論しよう!」というものでした。

現在、ビッグデータを活用するソリューションをAzureで構築しようとすると、Microsoft製品だけではなく、オープンソースのソフトウェアも利用できるようになっています。利用者としては選択肢が広がって便利ですが、その反面、数々のテクノロジを理解して適切に使いこなすことが求められ、敷居が高くなっているとも言えます。

そんな状況をサポートするためにMicrosoftからはビックデータのアーキテクチャガイドが提示されていますが、そうは言っても現場では当てはまらない場合も出てくるわけで。そんなノウハウをシナリオに応じて会場のみんなで議論できれば、ということでした。

まずは最初のテーマとして、以下のようなスライドが表示されました。

ひとくちにデータと言っても、現在のシステムで扱うデータの形式は構造化データ、非構造データ、バイナリ、動画などなど、多様になってきています。そんな多様なデータを適したところに入れて行くという概念が「Polyglot Persistence」ということです。

それをふまえて「ECサイトを構築する際に、それぞれのデータはどの形式で格納するのがよいでしょうか」という問題でした。

DSC_0294

シンキングタイムスタート。静まりかえる会場。通常のTechSummitセッションではずっと演者の方の声が響いているのに比べると、異様な雰囲気です。

私も「全部RDBMSで……だと問題にならないから、ええとクラスター分析は分析って名前がついてるしHDFSかなあ」なんてもごもごと考えてみます。

しばらくして演者の方が、誰か案はありませんか、と促します。正解はないので、と。さらに静まりかえる会場。

ここで率先して何か言えればよかったのですが、正直そんなに詳しくない自覚がありますし、下手に発言すると「なんであんなこと言っちゃったんだろ」と後悔がぐるぐるしてその後の話に身が入らない予感がしたため、ここは聞く係になると決めて潜伏させてもらうことにします。

緊張感溢れる時間が流れた後、やっと一名の方が発言されます。素晴らしい。

その方が選択されたのがこちら。やはりRDBMSが多めです。

DSC_0295

それに対し、一つの例として演者の方々から示されたのがこちら。

商品履歴はJSONでドキュメントデータベースに入れる、購入履歴はレコメンデーション機能を実現するためにグラフデータベースに入れる、など。

DSC_0296

引き続き、議論は「SQLに適するものと適さないもの」という視点で進みます。

少しだけ会場が温まってきて、ちらほらと声が上がります。SQLはトランザクションが必要なもの、とか、NoSQLはIoT、とか。ひとしきり意見が出揃ったところでまとまったものが出されます。なんとなく認識はしていましたが、こうやって言語化されるとすっきりしますね。

DSC_0297

そこからデータレイクの紹介があり、最後は「過去のデータとお天気情報をもとに航空機の遅延予測をするシステムを作るには」というテーマとなりました。

これもまた参加者の方々からぽつぽつとあがる声を元にその場で構成が書き起こされ、最後は回答例が提示されました。

DSC_0307

DSC_0308

普段はWebや書籍なんかで完成したアーキテクチャ例を見て「まあ、そういうことだろうな」なんて思っているのですが、いざ真っ白な所から描いてみるとなかなか難しく、できあがった時に達成感があることが分かりました。

よく考えてみると実際の案件でも同じことが起こります。お手本として示されるアーキテクチャはあるのですが、それがそのまま案件に使えるわけではなく、要件に応じて選択して行くという過程が必ず発生しますし、そこが我々ベンダの腕の見せ所だと感じました。

それにしても、チョークトークは初めて出たのですが、なかなか難しいですね。せっかくのチョークトークという形式を最大限に活かすには自分もそのテーマについて一言あり、演者や他の聴講者と積極的にディスカッションするくらいの準備があってこそだと感じました。

まとめると

  • Azureでビックデータを活用するソリューションを構築するには、色々なテクノロジを選べるからこそ恩恵も悩みも多い
  • ビックデータのアーキテクチャガイドが提示されているが、実際はシナリオに応じてうまく選択する過程が発生する
  • チョークトークは準備して参加するともっと楽しい

でした。

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の作り方と簡単にブラウザ上での実行の仕方を記事にしたいと思います。 続きを読む