トップ > MicrosoftAzure

Build 2018 振り返りと気になったニュースや感想と考察

MicrosoftAzure イベント

Build2018 が終わりました。
日本では de:code2018 が始まります。

昨年は Build 2017 ではありがたいことにギョーム扱いで現地参加していましたが、今年の Build は国内組でした。
リアルタイムは初日のキーノート程度で、あとはニュースや Channel9 でキャッチアップしてました。
ニュースのまとめやピックアップ記事をこのタイミングで書いても仕方ないので、気になったことだけを頭の整理を兼ねてまとめておきます。

気になったニュース

Alexa Cortana 連携

Microsoft、「Cortana」とAmazonの「Alexa」の連携をデモ - ITmedia NEWS

Alexa から Cortana を、Cortana から Alexa を呼び出せる機能がクローズドベータになりました。

最近 Alexa Skill をいじっているので気になるところです。
Bot が Bot を呼び出すことに何のメリットが？と思うかもしれませんが、やはり Office 365 など Microsoft 製品との連携で分がある Cortana を、 Alexa が載っている製品から呼び出せるのは大きいのではないでしょうか。
逆にオフィスに大量にある Windows PC から Alexa Skill を呼び出せるということは、Amazon Echo がなくとも大量にデバイスが存在することになります。

クラウドで競合している Amazon と協調する動きができるのは面白いですね。

メモ帳が LF 対応

Windows 10 RS5で“メモ帳”が改行コードLFとCRをサポート - PC Watch

表題のとおり。 Microsoft loves OSS ですね。
それ以上言うことはないです。

Microsoft Storeアプリの開発者収益割合が 85% から 95％ に変更

「Microsoft Store」アプリの開発者収益配分を95％に - ITmedia NEWS

全然追ってませんでしたが収益比率相当いいですね。
スマホアプリの寺銭と比べると良心的に見えます。
何か作ってみたい気持ちになりました。
とはいえゲーム以外ですか。

Microsoft Azure

Cloud Platform Release Announcements for May 7, 2018 | Cloud Platform News Bytes Blog
上記記事 Google 翻訳版 | Bing 翻訳版

ニュースとしては上の記事を見ればすべてよしです。
Bing 翻訳を普段あまり使ってませんが、文脈理解して Azure を認識できるといいですね。
Azure については気になったもの、すぐに使いそうなものだけピックアップしておくことにします。

App Center - GitHub Marketplace

App Center はそこまで使えてませんでしたが、これで使う理由が高まりました。

Web App for Container - Authentication 機能追加

Blob Storage - Static Websites support

ちょうど3ヶ月ほど前に Azure 静的サイトをホスティングしようと思った時はわりと面倒な手順を踏んでいました。 kheiakiyama.hateblo.jp

Leverage Azure Blob Storage to build storage intensive cloud native applications | Microsoft Build 2018 | Channel 9
Storage だけで完結するのはいいですね。
Custom Domain + SSL の場合は CDN 必要なようです。
まだ使っていませんが、AWS の S3 に追いついたと思ってよさそうです。

Function でホストしたサイトを近日載せ換えてみようかと思います。
(de:code 終わってからかな・・・)

Blob Storage - Tiers and Lifecycle Management

Blob Storage は 料金表 を見るとわかりますが、ホット・クール・アーカイブの Tier に応じて容量課金・アクセス課金のテーブルが変わります。
この機能は n 日経過したオブジェクトの Tier を切り替えたり、削除する設定が可能になるというものです。

Leverage Azure Blob Storage to build storage intensive cloud native applications - YouTube
大量のデータを預かっているサービスでは効果がありそうです。
もっとも v2 を使わないといけないので、v1 を使っている古いサービスではマイグレーションを頑張る必要がありそうです。

AKS - DevOps, CI/CD

Getting started with CI/CD & Azure Container Service (AKS) powered by VSTS | Microsoft Build 2018 | Channel 9

AKS 自体はプレビューかつ日本リージョンが来ていない状況ですが、デプロイ周りや監視ツールの整備が急速に進んでいるようです。
あまり k8s に詳しくなくても使えてしまいそうに見えるのが Microsoft らしい気がしています。

Azure 以外

Microsoft Teams

Microsoft Teams をあちこちで推し始めてるのが気になりました。
正直 Windows クライアントがもっさりしていて、現時点では Slack には及ばないイメージですが、競争自体は善なのでがんばってほしいです。
優位性としては Office 365 を使っている企業はかなり多いので、追加費用なしに利用できるのは大きいです。
Slack 、SSO やメッセージの有効期限を欲しいとそれなりにお金かかりますからね。。

Microsoft Graph

最近 Office 365 API を調べていたのでちょうと気になった話。

Office365 の API を扱うソリューション、と思っていたらそうではなく、Windows や Azure Active Directory など他も含めての API 群のような位置づけになるようです。
channel9.msdn.com

Office 製品の優位は当分揺るがないと思うので、このあたりは今後周辺サービスを提供するサードパーティー企業からすると注目されそうに思います。
特に Cortana や Alexa などスマートスピーカー製品のように、今後発展していく分野で使っていきたい気持ちがあります。

Blazor

C# で Single Page Web Application が書ける Blazor が凄かった件 - Qiita

Qiita の記事がバズっていたときは流してましたが、動画のデモを見たらよさそうだと感じました。

.NET Overview & Roadmap - YouTube

多少アセットのダウンロードが遅くても許容できるエンタープライズ系のWebサービスなら使えるのではという印象。
今回 Microsoft が独自の CDN を始めることが発表された のと合わせて、Blazor が使うアセットのうち標準ライブラリは Azure でホストしていれば標準で Microsoft CDN が配信するとか、今後の発展があるのではないかという妄想をして面白がっています。

最後に

全体的にこれはいらないのでは？というようなものが見当たらず、誰かが欲しいと思っているものが順当に出てきている印象です。

また、今回の Build 2018 では Channel9 のセッション動画は Youtube にアップロードされており、このあたりでも Microsoft が変革しているのを感じ取れて面白かったです。
やはり CEO が変わったことは大きいですね。

Hit Refresh（ヒット リフレッシュ）

Hit Refresh（ヒット リフレッシュ）

帰省ついでに Azure IoT Hub を試してた

MicrosoftAzure RaspberryPi やってみた

はじめに

2年くらい前から温度湿度をラズパイで取得することをやってた。
kheiakiyama.hateblo.jp

GrowthForecast で可視化していたものの、ラズパイ自体にはグローバルからアクセスできるようにはしていないため、帰省しないと見えないという不満があった。
それをいい具合にしたいと思って IoT Hub を試す決意をしていた。

Azure IoT Hub は Free プランが1日8000メッセージ受信できる ということで、毎分メッセージ送っても使えるのがよさそうだった。

やったこと

試したのはこのあたり。

ラズパイからセンサーデータを IoT Hub に送り、Web App でリアルタイムを見れるのができた。

知見

ラズパイ と Python Azure IoT Hub SDK つらみ

ラズパイ(デバイス)側はいろんな言語が選べる。
はじめに Python 使ったところ Azure IoT Hub の SDK の導入で苦しんだので Node にスイッチした。

Web App の Node version 問題

Free プランだったからかもしれない。
しかし Free プランで Socket I/O 使えたり Azure AD のシングルサインオン連携したりいろいろできて Web App は素晴らしいと思う。

可視化できてない件

リアルタイム可視化はできたけどデータ蓄積するところ作ってなくて全然やりたいことできてない。

そもそもセンサー壊れてた問題

ラズパイの死活監視は個人 Slack に流してるので問題ないのだが、温度湿度センサーが壊れていたことに気づかなかった。
今思うと Mackerel に流してた(こちらも Free プランなのでログは1日まで)ので、そこからアラートしていればもっと早く気付いたのに。
帰省で気付いて次の帰省までに買って持っていく、というの時間がかかってよくない。

ステージング環境というか別環境を都内に作るか。 せっかく ansible で管理していることだし。

あとがき

あまり問題は解決してないけど限られた時間で手を動かすのはよい。

サインスマート DHT22/AM2302　デジタル温度センサーモジュール RB206　for Arduino 電子工作

サインスマート DHT22/AM2302　デジタル温度センサーモジュール RB206　for Arduino 電子工作

Azure Logic App と Travis CI を使って翻訳サイトを静的ホスティングする

MicrosoftAzure 作った

kheiakiyama.hateblo.jp

先月静的サイトホスティングについて試した。

延長線上で、サイトのコンテンツを自動生成するサンプルを作った。

github.com

デモサイトはこちら 。

仕組みについて

trans-feed では jekyll を使って静的サイトとして生成している。

翻訳記事の生成

Logic App はかなり安価で、翻訳(Cognitive Service) は現時点で無料で使える。
図で表すと以下のような形だ。
f:id:khei-fuji:20180321170353p:plain

ここでは翻訳したファイルを Markdown で保存する。

ホスティング

f:id:khei-fuji:20180321170403p:plain

ホスティングについては特に 前回の記事 から違いはない。

デプロイ

f:id:khei-fuji:20180321170407p:plain

翻訳したファイルとリポジトリを Travis CI でまとめる。
jekyll build した結果を Azure Blob Storage にアップロードする。

Azure Function Proxy の proxies.json も Travis CI で生成するようにしている。
Let's Encrypt の証明書を利用したい場合に、jekyll のファイル配信用プロキシと Let's Encrypt の Extension 用のプロキシが共存できるように書くのが困難で、jekyll 部分の設定は自力で書くようにしたため。
いい書き方があるのかもしれないが、ドキュメントが少なくたどり着けなかった。

Azure Functions でのプロキシの操作 | Microsoft Docs

おわりに

Azure の公式ブログ読むときに概要読んでパッと取捨選択したいと思い、今回のサンプルに至る。

書いてて気付いたが、サイト作らなくても RSS を翻訳してそのまま Slack などに流せば要求満たせる気がしてきた。
まあ jekyll を少し試したかったのでよし。

しかし、ぶっちゃけ翻訳の精度は・・・

Azureテクノロジ入門 2018

Azureテクノロジ入門 2018

Azure Function Proxy を使って静的サイトをカスタムドメインかつHTTPSのホスティングする

MicrosoftAzure

キーワードを詰め込んだら長いタイトルになりました。

静的サイトのホスティング方法

Azure で静的サイトをホスティングするにはいくつか方法があります。

  • Azure Web App
  • Azure CDN + Blob Storage
  • Azure Function Proxy + Blob Storage

大まかに3つあります。

Azure Web App

オーソドックスな方法です。
カスタムドメインを適用するには Shared プラン以上が必要なので、日本リージョンで運用するには大体月1000円以上かかります。(公式:App Service 料金)
このパターンについてはギョームで使っているのでそのうち別媒体で書きます。

Azure CDN + Blob Storage

費用はアクセスが少なければ月数十円で済むでしょう。

なぜ Blob Storage の手前に CDN を挟む必要があるかというと、以下の記事が大変よくまとまっています。

Azure BlobでのWebサイト公開がつらい

Blob Storage のツラみを CDN でどうにかしてやろうということです。
CDN が SSL 証明書の面倒を見てくれるということで大変ありがたいです。
スケーラビリティも言うことなしでしょう。

しかし CDN で URL Rewrite するルールの適用が4時間以上かかるということで、待つのがかったるいです。
この記事を書いている間は絶賛待機中なのですが、待っている間に Function で試したところ動いたのでもういいかというところが今ココです。

Azure Function Proxy + Blob Storage

こちらも費用はアクセス次第ですが数十円から運用可能です。

Blob Storage で管理しやすいように管理するコンテンツの URL を Function Proxy でいい感じに整えるという役割分担です。
カスタムドメインや SSL 終端は Azure Function が担当します。
なお、今回の例では SSL証明書 は Let's Encrypt を使っているので無料です。

実現方法

ということで本題。

完成品

まずは成果物です。

kheiakiyama's CV

(2018/7/8 追記: こちらの記事で Blob の Static Website によるホスティングに変更済み)

コンテンツは何でもいいですが、Jekyll で作成したレジュメっぽいものを置いています。

GitHub - kheiakiyama/kheiakiyama.github.com at 12dc107f19cdea04a73fd72ec877c2e1f57acf13

余談ですが Octopress はどこに行ったんでしょうね。

GitHub から Blob Storage へのデプロイ

Web App には GitHub からの継続的デプロイ方法が提供されていますが、Blob ではもちろんありません。
そこで Travis CI を使っています。

kheiakiyama.github.com/.travis.yml at 12dc107f19cdea04a73fd72ec877c2e1f57acf13 · kheiakiyama/kheiakiyama.github.com · GitHub

デバッグ用コード多めです。
(上のリンクを開いた前提で)やっていることをざっくり書くと以下のとおりです。

  • Jekyll のビルド
  • .NET Core のインストール
  • AzCopy のインストール
  • AzCopy で Jekyll の成果物を Blob にコピー

Travis CI の権限周りがよくわからなかったので .NET Core のインストールはコピーしてきて手元で動かすだけという雑な作りになっています。

また、AzCopy で set-content-type しないと Blob 側の配信がすべて application/octet-stream になるという悲しい現象が起きるため、拡張子ごとにコピーするというイケてないコードになっています。
Function でヘッダーを上書きするのもありますが、Blob の時点で動作確認できる方が原因切り分けの面で有利なので Blob で実現しています。
コンテンツの一部ファイルが削除された場合など考慮することが他にもありますが、まずはこれで。

Azure Function の実装

proxies.json は以下のとおりです。

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "blob-route": {
            "matchCondition": {
                "route": "/"
            },
            "backendUri": "http://{your_storage}.blob.core.windows.net/{container}/index.html"
        },
        "blob-index": {
            "matchCondition": {
                "route": "/index.html"
            },
            "backendUri": "http://{your_storage}.blob.core.windows.net/{container}/index.html"
        },
        "blob-asserts": {
            "matchCondition": {
                "route": "/assets/{*file}"
            },
            "backendUri": "https://{your_storage}.blob.core.windows.net/{container}/assets/{file}"
        },
        "letsencrypt": {
            "matchCondition": {
                "route": "/.well-known/acme-challenge/{*rest}"
            },
            "backendUri": "https://%WEBSITE_HOSTNAME%/api/letsencrypt/{rest}"
        }
    }
}

Blob Storage から取得したいファイルを Proxy する以外では Let's Encrypt の承認プロセスのための API を Proxy しています。
このあたりは 公式の Wiki に書いてある通りに書いただけです。

Proxy 以外にも api/letsencrypt/{rest} の部分を実装する必要があります。
上述の公式の Wiki を参考に C# か NodeJS の内容をコピペしましょう。

余談ですが Azure ポータルと App Service Editor を両方開きながら相互に読み書きしたところ proxies.json が消えるハプニングが起きました。ローカルに適宜バックアップしながら作業を進めるのが無難です。

Azure Function でカスタムドメインと SSL の設定

カスタムドメインは 公式 でも見てください。

Let's Encrypt の導入については Azure Function でも Web App でも上記の Proxy 部分以外に差はありません。
How to install · sjkp/letsencrypt-siteextension Wiki · GitHub

公式の手順を参考に粛々と作業を進めましょう。
英語がニガテな方は以下サイトを参考にするとよさそうです。

Azure Web Apps に Let's Encrypt を使って簡単に SSL を導入する - えむにわリソース

無事完了すると SSL 証明書が割り当てられ、カスタムドメインと SSL バインディングされた状態になります。

f:id:khei-fuji:20180212164429p:plain

https://{your_site}.scm.azurewebsites.net/.well-known/acme-challenge/{*rest} のリダイレクトでエラーになった場合は Function Proxy の実装が上手くいっていないと思われます。
一つずつ見直しましょう。

参考にした記事

最後に

Proxy は書き換え直後にすぐ動くので使っていて気持ちいいです。
最初に上げた通り、実現方法のパターンはいくつかありますが、要件に合わせて適切に使っていきたいものです。

Azureテクノロジ入門 2018

Azureテクノロジ入門 2018

Azure 系エンジニアから見た GAE 〜Google App Engine編〜

GCP MicrosoftAzure

前回に続き GCP。今回は Google App Engine こと GAE。
スケーリングが柔軟なWebアプリケーションの PaaS で、Azure でいうと Web Apps、AWS では AWS Elastic Beanstalk のはず。
Heroku を卒業したサービスが仮想マシンベースのサービスに引っ越すか、このへんに引っ越すイメージ。

Google App Engine

料金

全般

App Engine の料金  |  App Engine Documentation  |  Google Cloud Platform

価格 - App Service | Microsoft Azure

GAE の料金体系は、インスタンス(CPU+メモリ)とデータストア、ネットワークトラフィック、あとはコンポーネントによって定義されており、見積もり泣かせな細かい設定となっている。

Azure の Web App 同様、強力なプラットフォームを利用できる代わりにベースの料金はそれなりにかかる模様。
(Azure App Servie ではCPU時間リミットがある無料プランや、プロダクションでは月1万円欠けるスタンダードプランなどがある)

GCP: Instance classes

(B or F) + 数字 の組み合わせでインスタンスが表現される。
数字が CPU 性能で 4_1G 以外は CPU 性能に合わせてメモリ量が増える。
B と F の違いはこの後出てくるスケーリングのタイプによって変わる。

カスタマイズしたインスタンス

フレキシブル環境という仕組みがあり、CPU とメモリのサイズをアプリケーションに合わせてカスタマイズできる。

無料枠

各リソースごとに無料枠が設定されており、たとえばフロントエンドインスタンスは 1日28時間分が無料となっているため、1インスタンスで足りるサービスならインスタンスについては無料でサービスできる。
なにかサービスつくりたい。

開発

全般

GAE ではアプリケーションに関する設定は各種 yaml ファイルで定義する。
app.yaml によるアプリの設定  |  App Engine flexible environment for Java docs  |  Google Cloud Platform

このあたりは GCP の哲学としてコードに残すのだ、という意志を感じる。

スケーリング

オートスケール

インスタンスクラスでいうところの F について。
GAE にはスケーリングのパターンがいくつかある。
オーソドックスな CPU 使用率トリガー以外に、レイテンシの時間をトリガーにできる。
リクエストを受けたキューがインスタンスに流す待ち時間が 500ms を超えたらスケールアウトするなど。

スケールインも細かい制御ができるのが他のクラウドと比べたときの特徴。
インスタンス数をロックするのも可能だが、無料枠の恩恵を受けられないので個人のサービスとしては迷うところか。

マニュアルスケール

オートスケールせずにインスタンス数を固定するのも可能。
この場合は B のインスタンスクラスとなる。

参考

App Engine Scaling Config - Qiita

上がまとまっていて参考になった。
動かすアプリケーションによって経験則による設定値がありそう。

デプロイ

デプロイはわりと時間がかかる。
オーソドックスな以下の app.yaml でも 10分〜15分くらいはかかった印象。

runtime: nodejs
env: flex

あとはスケーリングの変更を行った場合のデプロイは反映されるまでにかなり時間がかかったので詳しい動きを知りたい。
デフォルト設定で負荷をかけて10台くらいにスケールした後、manual_scaling で2台にするのにかなり時間がかかった。元の設定のスケールイン値に基いて2台になるのかも。

ホスティング

よくある Web の PaaS と同じ。

プロジェクトに複数のサービスがある場合は個別に FQDN が払い出される。
gcloud app deploy app.yaml service1.yaml service2.yaml でデプロイ。

カスタムドメインも普通に使える。

よくわかってないところ

シークレット情報としての環境変数

環境変数は app.yaml に書く以外の方法が用意されていない。
API Token などのシークレット情報をどこに置けばいいかがわからない。
Azure Web App や Heroku だとクラウドリソースのメタデータとして設定するが、yaml 以外に設定値を持たない GAE でどうすればいいかがわからない。

調べた限りだと Data Store を使ったり、Cloud Storage を使っている 回避策を取っている模様。
app.yaml を .gitignore するのはなしだろうなあ。
GAE は歴史が長いサービスなので、機能がないということはきっとこの先も機能提供されないのだろう。

サービスの落とし方

よくわかりませんでした。
アプリケーションを無効にして、インスタンスを削除すればOKですかね。
請求を後で確認。

最後に

基本的な部分を触っただけなので、まだ試したいことがいろいろ残っている感じ。
思いつくだけでも

  • 複数ドメイン利用するプロジェクトでどうアプリケーションコードを分割するのか
  • スケジューリングジョブ
  • npm や Composer, Nuget などのデプロイジョブ
  • 継続的デプロイ

ここまで個別にサービスを見てきたけど、どこかで小さいアプリケーション書いて動かしたほうが足りない部分がわかってよさそう。
時間を取れるときにやりたい。

Azure 系エンジニアから見た GCP 〜Cloud Storage編〜

GCP MicrosoftAzure

先週に引き続き GCP を見ていく。

前回は仮想マシン相当の Google Compute Engine だった。
Azure 系エンジニアから見た GCP 〜Google Compute Engine編〜 - ぐだぐだ言ってないでコードを書けよ、ハゲ。

今回はファイルストレージ相当の Cloud Storage。
Azure では Blob Storage、AWS では S3 にあたる。

Cloud Storage

料金

全般

Azure Storage Blob の価格 | Microsoft Azure

Google Cloud Storage の料金体系  |  Cloud Storage ドキュメント  |  Google Cloud Platform

アクセス頻度に基いてどのタイプを使うか選択する。
Azure は単リージョンに置いたとき(LRS)と複数リージョン(GRS)に置いたときで容量課金が純粋に倍になるが、GCP はそうでもない。
GCP ではマルチリージョンで細かいリージョン指定ができないので、東京のように高いリージョンは使われていなくて、結果的に料金が安く見えてるのかもしれない。

マルチリージョンでないプランならリージョンを指定できる。

余談だが Azure の料金プランは V2 ができつつある関係ですごく複雑になっていて見通しがよくないのでつらい。

SLA

細かい話だが SLA に関する対処は横並びっぽい。

料金プランの適用範囲

Azure だとストレージアカウント単位で料金プランを選ぶが、GCP では料金プランを意味する「ストレージ クラス」をオブジェクト単位で指定できるようになっている。
バケットで指定する料金プラン(ストレージクラス)は、あくまでもオブジェクトの料金プランのデフォルトという位置づけ。
特定のオブジェクトのプランを後から変更するのも可能。

オブジェクトのストレージ クラスの変更  |  Cloud Storage ドキュメント  |  Google Cloud Platform

リクエスト課金

リクエスト課金の部分はアクセス元のプロジェクトに払わせることができる。
Azure Blob にはなかったはず。

アクセス

アクセス権限を細かいレベルで管理できるのは想像がつくので特に見てない。
静的サイトのホスティングも普通にできる。

https://storage.googleapis.com/(Bucket_Name)/(Object_Name)

バージョニング

バージョニングを有効にすると、ファイルをアップロードしたときに前バージョンが残る。
最新以外のファイルを操作するにはコンソール(Webのポータル)ではできず、cli ツールである gsutil を使う必要がある。

Azure だとバージョニングはなくて、スナップショットで取ることができる。

Creating a Snapshot of a Blob | Microsoft Docs

スナップショットは明示的取らないといけないので、有効にしておけば自動的に取れる GCP とどっちがいいかは良し悪しか。

GCP Console 周り

今回も Console でいいなと思った部分があった。

調べながら使うというところがすごくカバーされているのを感じる。
Google検索を持ってるから、どこで脱落しているかなどが手に取るようにわかっているのだろう。

あとがき

わかりやすくて機能が少ないサービスは軽く流していけるが、GAE みたいなサービスをどうやって見ていこうかちょっと迷う。
GCP は数年前に見たときのイメージで Go や Java, Python あたりが一級市民てイメージがあるので、ちょっとは書ける Python かこれからの Go を書きながら検証していくしかないのかな。Java は知らん。

Azure 系エンジニアから見た GCP 〜Google Compute Engine編〜

GCP MicrosoftAzure

昨年は Microsoft Azure をある程度キャッチアップできた気がするので、今年は Google Computer Platform をキャッチアップしていきます。
今回は公式チュートリアルの最初にあった GCE を見て気になったところをメモしてます。

GCE について

管理

GCP でははじめにプロジェクトを作成し、リソースはプロジェクトの中で作成します。
インスタンス単位で ssh 公開鍵を登録するのはもちろん可能ですが、プロジェクトで ssh 公開鍵を作成し、GCE の各インスタンスではデフォルトではプロジェクトの公開鍵を利用できるため、厳格なポリシーがなければこれで事足ります。

ネットワーク - プライベートアドレス

Azure では内部IP範囲が他の仮想ネットワークと重ならないようにデフォルト指定されます。
これは複数の仮想ネットワークをピアリング接続する可能性を考慮してのことだと思われます。

一方 GCP ではリージョンでデフォルトのIPが決まっていて、別のプロジェクトで作成したプライベートIPの範囲とは重なります。
割り切りですね。

このあたりは好みが分かれるな気がします。

ネットワーク - セキュリティグループ

Azure で言うところの NSG, AWS でいうところのセキュリティグループについて。
Azure ではルールセットである NSG を作成し、VMのネットワークインターフェースかサブネットにアタッチします。

GCP ではネットワーク全体かサブネットかタグにアタッチします。
VMインスタンスがタグを持つことで、特定のインスタンス向けのルールを作成できます。
プラットフォームが役割としてのタグを強制するのは、個人的には好きな対応です。

オートスケール

インスタンスグループという機能によってオートスケールを実現しています。

コンテナ

Azure では Docker コンテナを動かす Web App for Container というサービスがあります。
GCP では GCE でコンテナ機能が実装されていて、驚きました。
現段階ではアルファ版 ということなので、今後どうなるかわかりませんが、注目です。

インスタンスグループにローリングアップデート機能などもあるため、いろいろ捗りそうです。

GCP 全般について

ゾーン

GCP ではリソースを作成するときにゾーンを指定します。
ゾーンは {大陸}-{方角}{NO} となっているので、そのゾーンがどの国を意味しているのかはググって解決してました。
それでいて 料金 ページでは国が表示されるので「このリソースを作るといくらかかるんだっけ？」という気持ちになりました。

ポータル

Azure ポータルは遅いので、そこが快適な GCP は気持ち良いです。
Azure-CLI を使うという手はもちろんありますが、ここは見習って欲しいところ。

おわりに

次はストレージかデータストアあたりを見ていくはず、たぶん。