Hejdaの見る夢

一人前のエンジニアを目指して頑張ったこととかをつらつら書くブログ

プレビュー版 Azure Spot VMs を使ってみた🎉🎉

サマリ

  • Azure Spot VMs が新しくプレビューに追加されました。
  • 既に試用することが可能です。
  • 用途によっては、積極的に使っていきたい機能です。

経緯

2019/12/04 に @ThomasMaurer さんによって、以下のツイートがありました。

内容を簡単にまとめると以下のようです。

  • Azure Spot VMs というサービスがプレビューになったこと。
  • 上記のサービスは条件付きではあるけれど、 Azure VM をかなり割安で使用することが出来ること。
  • プレビューであるけれど、東京リージョンでも使えること。

関連するドキュメントは今のところ、以下の 3 点が公式ドキュメントとして見つけることが出来ました。

Azure Spot VMs とはいったい何か?

以下の特徴があります。

  • Azure VM を従来の金額から大幅に値下げした価格で使用することが出来ます。
  • VMスケールセット(VMSS)に対応しています。

とのことです。

これだけでも、インフラや SRE といった分野のエンジニアからすると、喉から手が出るほど欲しい機能です。

使用条件

VM のサイズの制限があり、以下の VM サイズでは Spot VM は使用出来ません。

実際に使ってみましょう

公式でチュートリアルが整備されています。

Azure portal

Azure CLI

Azure PowerShell

ARM テンプレート

Azure portal と Azure CLI を実際に試してみたいと思います。

試すだけであれば簡単で、登録などは不要なのですぐに試すことが出来ます。

Azure portal から試してみる

Azure portal >> Virtual mashines >> create virtual machine と選択すれば既に選べる状態になっています。

f:id:nari_kyu:20191207163308p:plain

また、Azure Spot instance を選ばなかった場合は Eviction type および、 Eviction policy の項が無くなるようです。

その後、諸々の設定を行い、最後に Create することで VM は起動します。

f:id:nari_kyu:20191207163441p:plain

いつもの VM となんら変わらないですね! 👏👏

Azure CLI から試してみる

Azure portal 上の Azure Cloud Shell から実行します。

それ以外の環境から実行する場合は、az コマンドのインストールや Azure への認証などが必要になります。

  • リソースグループの作成
    • 先ほど作成した spot-vm-test を使います。
    • 新しく作成する場合は下記のコマンドで作成出来ます。
az group create -n spot-vm-test-cli -l japaneast

### location を知りたい場合は以下のコマンドで確認が出来ます。
az account list-locations

ドキュメントに習って、 Azure CLIVM を作成していきます。

  • 環境変数を用います。
    • 試される場合は、この変数を好きな値に変更してください。
export _rg_name='spot-vm-test'
export _vm_name='spot-vm-test-cli'
  • az コマンドを用いて、 Spot VMs を作成します。
az vm create \
    --resource-group ${_rg_name} \
    --name ${_vm_name} \
    --image UbuntuLTS \
    --admin-username azureuser \
    --generate-ssh-keys \
    --priority Spot \
    --max-price -
  • 実際の Azure Cloud Shell の様子です。

f:id:nari_kyu:20191207165446p:plain

  • Spot VMs を作成した際に設定したログインユーザ名と、標準出力に秘密鍵(と公開鍵)の PATH および、 パブリック IP アドレス が出力されているので、その情報を元に SSH ログインしてみます。

f:id:nari_kyu:20191207170558p:plain

こちらも無事 SSH 出来ました!! 👏👏

ちなみに この VM は Spot VMs か否か を判断したい場合にどこを見ればいいか、現時点では分かりませんでした。

こちらは分かり次第、追記したいと思います😉

リソースの削除

作成した VM はいくら Spot VMs とはいえ課金が発生してしまうので、不要なったらリソースグループごと消してしまいましょう。

f:id:nari_kyu:20191207175239p:plain

まとめ

プレビュー版なので仕様変更がある可能性が高いですが、それを差し引いてもすぐにでも積極的に使っていきたい機能です。

個人的な思い

※ ここから下は完全に個人的な感想です。

このサービスはすべてのリージョンで使用出来ることや、ほぼすべて VM サイズで使用出来ることもすごいのですが、個人的には VM スケールセット(VMSS) に対応してるというのがとても意味が大きいと考えています。

昨今は PaaS を代表としたインフラを考慮しない設計が注目を浴びていますが、要件によっては VM を扱わなくてはならず、VMスケールセット を構築している環境も多いと思います。

Azure Spot VMs は 中断できるワークロードに最適 とあるように、ユーザ側の意図しないタイミングで落ちる可能性があります。

これが逆に良くて、この条件を加味した VM に依存しないアークテクチャ設計 を求められることになり、結果的にインフラレイヤーにおけるカオスエンジニアリングを意識したアーキテクチャを考えざるを得ない状況になると予想します。

結果として DevOps や SRE といった基盤よりのエンジニアの腕の見せどころとなり、よりクラウドネイティブな設計をさざるを得なくなります。

さらに個人的な願いとしては AKS の Node に使いたいと思っていて、何か貢献出来ればいいなぁと思いつつ、 CLI および Terraform の実装待ちというステータスです😊

Microsoft Learn もくもく会に参加しました(※ 注意書き有

注意点

※ 当日はわたしは咳喘息の悪化に伴い、本当は参加していません!!

※ この記事は、行きたかった気持ちを供養する記事です…

Microsoft Learn もくもく会とは

紹介

今回は、第10回 Microsoft Learn もくもく会 @品川 に参加してきたので、その時のメモになります。(※ 参加出来ていません)

雰囲気や内容を把握して頂き、今後参加される際の参考になればと思います。

あと、 Twitter でおだしょーさん(@MS_odasho)を追いかけていると、より詳細な雰囲気が掴めると思います

楽しそうですよね!! :)

当日の時間の流れや雰囲気

ざっくりなスケジュール

  • 12:30 ~
    • 受付
  • 13:10 ~
    • 会の説明
  • 13:15 ~
    • 自己紹介
  • 13:20 ~
    • もくもくタイム開始
  • 16:45 ~
    • 成果発表
  • 17:00
    • 解散

雰囲気

  • (普通の?)もくもく会
  • 飲み物はフリードリンクをいただけるので、適宜動く感じ

あまりツイートが見つからなかったので、みんな集中してやっていたのかなと思います!

アドベントカレンダーについて

話しが変わるのですが、すこし前に Twitter で以下のやりとりがあり、 Microsoft Learn のアドベントカレンダーを作ることになり、勉強会でも紹介がありました。(これは予想)

今回はこのアドベントカレンダー作成と実施も兼ねて参加したので、効率的に時間を使えたかと思います。(※ 参加出来ていません)

なお、勉強会後は有志で夕飯を食べに行ったそうなのですが、私は次の予定があったので、先に帰りました。

次回参加出来る機会があれば、ごはんまでご一緒出来るといいなと思います :D

わたしが作成しているコレクション

まとめとか感想とか

Microsost learn は本当にすごくよく出来たサービスであり、もろもろのサービスの質や量、認定精度、社員さんの対応などを考えると Microsoft の本気というか、ある意味 余裕さ さえ感じました。

本当にエンジニア(も)を大切にしているんだなという印象が他のクラウドよりもより強く感じます。

しかし、 Microsost Learn はキッカケでしかないため、ここで得た知識や技術を使って実際に Azure を動かして、なにかアウトプットをしたいなと思います!! ;)

Azure Citadel のすゝめ 🧐

サマリ

Azure Citadel に感動したのでそれをおすすめする記事です!!

f:id:nari_kyu:20191104143355p:plain

どんなサイトなの??

https://azurecitadel.com/about/

簡単にまとめると以下のようです。意訳なので間違ってたらごめんなさい :(

  • Azure Citadel はイギリスのとあるコミュニティチームに属している、数人の Microsoft クラウドアーキテクト達が共同で立ち上げたコミュニティサイトである。
  • Microsoft の公式なサイトではない。
  • イギリス国内外問わず、 Microsoft (社員) 外の技術的なコントリビューターによるコントリビュート (contributes) が存在している。
  • 記事に前提知識が必要なものも少なくなく、 Azure への基礎的な理解は Microsoft Learn などの公式の Microsoft サイトを参照すること。

また、閲覧のみであれば会員登録も必要無く自由に閲覧することが出来ます。

GitHub Pages でホスティングしているので、ページのソースを見ることも出来ます。

具体的にどんなものがあるの??

2019/11 現在のカテゴリーとその説明は以下の 11 項目

https://azurecitadel.com/categories/

f:id:nari_kyu:20191104143336p:plain

  • Automation
    • Operate at scale and manage your cloud resources optimally through governance and automation. Subscribe to the feed in the footer!
  • Cloud Native
    • Understand how to build cloud native, modern apps with containers, serverless & Kubernetes.
  • Data & AI
    • Real world AI with cognitive services, bots data-analytics and machine learning.
  • DevOps
    • Deploy & build software faster through pipelines, with automation and DevOps practices.
  • Fundamentals
    • Core concepts of Azure and information on getting started for beginners.
  • Infrastructure
    • Virtual machines & networking are still the backbone of many cloud architectures.
  • Internet Of Things
    • Build production-grade IoT applications and configure your IoT solution.
  • Pre-Reqs
    • Get yourself set up and ready to take on the labs.
  • Security
  • Specialised Workloads
    • Specialised topics such as SAP, HPC and other demanding enterprise workloads.
  • Web & Mobile
    • Developing using web & mobile platforms using RESTful APIs. Azure platform services and API management.

感想とか

Microsoft Learn や 公式ドキュメントもありますが、Azure Citadel は(自分の GitHub に誘導することも出来るなどの)エンジニアとしてある程度自由度を持ったコミュニティのように感じました。(もちろん Azure Citadel で完結する記事も多くあると思います。)

そして、記事や閲覧者が増えることによって、コミュニティとしての成長の余地は十分にあるサイトだとも感じました。

将来、このようなコミュニティサイトで多くのエンジニアが自分の価値を表現出来ると期待しています。

いつの日か、自分でも(もちろん英語で)投稿出来るように頑張ります :D

Google 公式ドキュメントにコントリビュートした時のまとめ(Contributor License Agreementの話も)

サマリ

Hacktoberfest 2019 に参加する流れで Google の公式 Repository の 1 個に Pull Request(以下、PR)作ってみようと思いました。

偶然にも修正するべき変更点を見つけることが出来たので、 PR を作り、 Merge されるまでの流れを簡単に記したいと思います。

この流れの中で Contributor License Agreement (以下、 CLA) というものにも出会ったので、記しておきます。

変更点

今回、 PR を出した Repository は GoogleCloudPlatform/nodejs-docs-samples であり、 GCP の公式の Repository になります。

その中で実際に発見し、修正した変更点はとあるディレクトリの中の README の中の リンクが変に切れていた 箇所があったのでそれを修正するものです。

実際の変更点は以下になります

## Run the tests

1. Read and follow the [prerequisites](../../#how-to-run-the-tests).

1. Install dependencies:

        npm install
  • After
## Run the tests

1. Install dependencies:

        npm install

修正自体は簡単なものだったのですが、 PR を作るまでに以下の 2 点を調べます。

  • なぜ、このような(リンク先が無くなる)ことが起きたのか
  • 変更内容が妥当だと思う根拠はなに(どれ)か

これは、 PR を作る際に、根拠として需要になってくるからです。

このリンクが死んだタイミングを調べる

なぜ、このような(リンク先が無くなる)ことが起きたのか変更内容が妥当だと思う根拠はなに(どれ)か についてはだいたい調べは終わりました。

同じようにリンクが出来なくなっている箇所が他に無いか確認する

ここまでで修正する根拠は見つけられましたが、他にも同じような箇所が無いか確認しておきます。

  • 流れ
    1. ブラウザ上で人力で探すのは厳しかったので、 Repository をローカルに clone した後に grep コマンドで探しました。
    2. 結果的には無かったので、変更点は 1 ファイルのみということが分かりました。

PR を作る

順番としては以下のようにやりました

  1. オリジナルの Repository (GoogleCloudPlatform/nodejs-docs-samples)を自分のところに Fork する(iganari/nodejs-docs-samples)。
  2. Fork した Repository にて feature ブランチを作り、そこで修正する。
  3. オリジナルの Repository に対して PR を作成する。

PR 作成まで、問題無く進みました!

Contributor License Agreement (CLA) に署名する必要がある

PR 作成直後

PR を作ったすぐ後は、以下のようになります。

f:id:nari_kyu:20191104060937p:plain f:id:nari_kyu:20191104060956p:plain

これは Google Open Source Project に指定されている Repository に コミットする場合(正確には commit した時のメールアドレスを確認している)に、署名が必ず必要だからです。

内容的にはソフトウェアに対しての権利関係の同意書になります。

詳しくは下記を参照して下さい。

CLA に署名していく

googlebot から促されたリンクをクリックし、 CLA に署名をする流れです。

f:id:nari_kyu:20191104061105p:plain

  • 実際にコントリビュートする際に、またその後に関しても重要なので、ちゃんと目を通しましょう。

f:id:nari_kyu:20191104061122p:plain

  • 同意であれば、必要事項記入に進みます。

f:id:nari_kyu:20191104061147p:plain

  • 必要な項目を埋めましょう。

f:id:nari_kyu:20191104061205p:plain

  • 正常に記入が完了すれば、以下のようになります。

f:id:nari_kyu:20191104061216p:plain

googlebot に伝える

  • PR の中にコメントがあるように、 googlebot に対して CLA にサインした旨を伝えます。

f:id:nari_kyu:20191104061227p:plain

その後はレビュアーが確認するフェーズになりますので、こちらは待ちのステータスになります。

残タスク

残タスクとしてレビュアーが確認した際に、過不足や的はずれな修正内容だと、指摘が入るかもしれません。

定期的に確認したほうがいいかと思います。

結果と感想

PR 作成から 3 日後にレビュアーの確認が始まり、次の日には Merge されていました。

幸いにも指摘のやりとりが発生するような大きな修正では無かったし、ちゃんと根拠も記載したのが良かったのかもしれません。

今回の経験で、公式ドキュメントでもちゃんとやり方を守れば、自分でも修正出来るという経験を得られたのは大きかったと思います。

これからもいろんなことに臆せず挑戦していこうと思います!!