Azureのファンであり続ける大変さ

2021/09/30 06:57

Alex Hudson
スタートアップおよびスケールアップ企業のポートフォリオに対するアドバイザリーCTO
この記事は、著者の許可を得て配信しています。
https://www.alexhudson.com/2021/09/17/its-tough-being-an-azure-fan/

AzureはカテゴリーリーダーであるAWSに属しているのですが、これまでAzureはナンバーワンのクラウドプロバイダーではありませんでした。しかし、多くの人が考えるように、Azureが第2位だということはかなり妥当なことであり、必ずしもAWSと大きく差別化されているわけではないけれども、特筆すべき点は十分にあると言えるでしょう。

しかし、Azureテクノロジーのユーザーやファンでさえも、Azureをクラウドプロバイダーとしておすすめすることがますます困難になってきています。

さて、私はGartner社(2021年7月の時点で、Azureをカテゴリー「リーダー」と評価し、競合はAWSとGoogleだけとしている)の社員ではないので、私の意見を気にする人はいないでしょう。しかし、このようなテクノロジーを常に評価しているCTOとしては、Azureが現在間違った方向に進んでいる点について記事を書く価値は十分にあると思います。

私は、あらゆる使用目的があるため、多くのクライアントでAzureを使用しています。ユーザー認証も強力ですし、Windowsデスクトップとサーバーのワークロードを実行する能力もあります(それがお好みであればの話ですが)。Azureは、AWSよりも安価な場合もあれば、より多くの、より優れたものを提供する場合もあり、また、いくつかの分野(CosmosDBのような)では、実際にまったく異なる魅力的なサービスを提供しています。

また、私はAzure devrelの大ファンでもあります。Code FunctionsからStatic Websitesまで、さまざまなことについてTwitterに投稿してきましたが、必然的にAzureからは、魅力的で知識豊富な人たちが現れます。Azureのコードの多くはGitHubで公開されており、その内容を確認するのは簡単です。

このように、ポジティブなことはたくさんあります。しかし、ネガティブな要素も増えてきており、それらを具体的に指摘する価値はあります。

セキュリティ

そうです。もちろん、この話抜きには語れません。ここ数週間前から、Azureは本当に破滅的なセキュリティインシデントに見舞われています。

  • CosmosDBのJupyter統合で、リモートからの「自分のデータベースへのアクセス」という脆弱性が発生しました。それに対してはすぐに対応がありましたが、多くのユーザーが影響を受けました。この脆弱性が利用されて被害を及ぼしているようには見えませんが、原理的には完全なDBアクセスが可能です。
  • Azure Container Instances(ACI)には、ACI 内の他の顧客の情報にアクセスできるという脆弱性がありました。この場合も、関係する顧客の数は限られており、悪用は検出され被害が出ることはありませんでした。
  • Azure VM 管理拡張機能には、ちょっとした認証バイパスの脆弱性があり、拡張機能がインストールされたすべての Linux コンピュート VM に影響を与えます。これは、実際には全て関連した問題であり、そのうちの1つは、CVSS 3.0スケールで10点満点中9.8点を獲得したリモートコード実行の脆弱性(つまり、最悪の部類)です。

Microsoftがこの件に関してオープンで透明性の高い対応をしており、素晴らしいと思いますし、私も自信が湧いてきました。また、Azureが、最大6万米ドル相当のバグ報奨金を伴う新しいセキュリティ・リサーチ・チャレンジを発表してから約1ヶ月の間に、これらの脆弱性が見つかったのは偶然ではないでしょう(これも良い動きです。Microsoftはよくやってくれました)。

しかし、これらの脆弱性は恐るべきものです。Azureは、ISO 27001/27017に準拠したマネージドクラウドサービスであり、SOC 1、2、3の認証を受けており、その他にも言及しきれないほど多くの認証を受けています。これらの証明書はいずれも、Azureの情報セキュリティ管理システムが適切かつ効果的であることを示しています。

バグのないシステムや安全なシステムはありません。しかし、リクエストから認証ヘッダーを削除することで、管理インターフェイスのセキュリティがバイパスされるとは思えません。ここ数年、Microsoftのセキュリティに対する評判はずっと良かったのに、またしても危険にさらされているのですから。

継続的なデリバリー

この話を出したのは、私がこれにイライラしているからです。私たちは皆、継続的なデプロイメントやInfrastructure as Code(IaC)について話していますが、Azureにはこれを可能にするいくつかの興味深いツールがあります。個人的には terraformを使っていますが、何を使うかは人それぞれで、terraformを使う必要はありません。

通常、Azureを利用するには、azコマンドラインユーティリティを使用する必要があります。これにより、Azureへの認証が行われ、実質的にすべてのAPIへの管理アクセスが可能になります。これは、Pythonで書かれ、オープンソースとして提供されている、素晴らしく機能的なツールです。

しかし、このコマンドをインストールしたい方は注意してくださいね。実はこのコマンドは強烈なモンスターで、今は1ギガバイト以上の重さがあります。この問題は2018年にバグが指摘されてから知られるようになりましたが、当時のユーザーにとってはそこまで悪影響はなかったと思います。その段階では数百メガ程度だったので。

根本的な原因は、恐ろしく肥大化したAzure Python APIにあります。Microsoftの後方互換性はもちろん伝説的なものですが、Python APIでは、互換性のない変更のたびにAPI内のコードフォークが発生したのです。レポを探索すると、それぞれのサブディレクトリが他のサブディレクトリとほとんど同じように見え、映画『インセプション』のような体験をすることになります。

さらに、これらの古いAPIに対応するために、Microsoftはユーティリティーが正しく動作することを保証するようpythonランタイム全体をパッケージ化しました。そして、すべてのpythonバイトコードキャッシュ。ほぼ準備完了です。

では、なぜこれが問題なのでしょうか?多くの人がそうであるように、私もソフトウェアのビルドのほとんどをコンテナベースのパイプラインで実行しています。私は、小さくてスリムなコンテナイメージと高速な実装するときの時間が好きです。ログインして基本的なAPIコールを実行するために1GbのPythonを使用するのは、時間、ストレージ、その他の要素のものすごい無駄になります。このストレージの損失は、一貫したDockerキャッシュを持つ静的なワーカーがない限り、パイプラインのトリガーごとに支払われることがあります。

単純な事実として、az-cliはDockerのようなシナリオでは事実上使用できず、悪化する一方です。何かが変わらない限り、1年ほどで使用できなくなるでしょう。ではどうするべきなのでしょうか?自分たちでAPIを手動で呼び出すのでしょうか?私たちが実行する必要のあるいくつかのコマンドのために、カスタムドロップインのazの代替品を書くのでしょうか?さあ、Azureよ、もっといい製品を目指してください。

コンピューティングのコスト

すべてのクラウドプロバイダーには、高価な「モノ」があります。イングレスは常に安く、エグレスは常に高いものです。AWSには「マネージドNATゲートウェイ」がありますが、これは決して失敗することのない、放置されているお金の印刷屋さんです。

しかし、私はAzure App Service Planに勝るものはないと思っています。これはマネージドVMと呼ばれるもので、通常、コンテナやその他のパッケージワークロードを自動的に実行してくれます。

Azureには素晴らしい無料プランがありますし、開発者向けのモデルも安く提供されているので、不満はありません。期待していなければ1GBのプランが無料で手に入りますし、英国で開発/テスト用の小規模な共有環境が欲しい場合は月7ポンドを支払えばいいのです。すばらしいですね。

さて、私はアプリを開発し、MVPを本番に進める準備ができました。まずは1.75GiBのRAMと、少しのローカルストレージが欲しいところです。金額はいくらかって?価格は月額70ポンドです。1桁違います、どういうこと!?

さらに悪いことがあります。上のインスタンスには1つのコアしかなく、それはS1です。2コアのマシンに3.5GBのRAM(大したスペックではありませんが...)を搭載した場合、月額136ポンドになります。すごい。年間コストは1,600ポンドで、永続的なストレージやデータベースなどは何も追加していないのです!

もし基本的なLinux VMが欲しくて、自分でdocker run...と入力する気があるなら、同じようなマシンスペック(B2ms)を月25ポンドで手に入れることができます。つまり、コンピューティングに20%、管理する経費として80%を支払っていることになります。

確かに、これは同一条件での比較ではありませんが、私はApp Service Planにお金を払いたいとは思いません。管理されたデータベースや管理されたゲートウェイについても同じことが言えます。

競合他社はどうなっているのでしょうか?AWSのECSインスタンスは、基本的にEC2インスタンスのコストと同じです。ロンドンのt3.medium(2 vCPU, 4GiB RAM, EBSストレージ)は、私がこの記事を書いている時点では、オンデマンドで0.0472ドル/1時間です。同じ仕様のAzure Linux ACIインスタンスは0.11364ドル/1時間です。同じことをするのには、さらに80ドル/月を支払うことになります。

こういった小さな違いが、あっという間に積み重なっていくのです。

障害発生

みんなが恐れる言葉ですよね。誰もがダウンタイムを嫌います。ほとんどのクラウド・プロバイダーは、どこかの段階でダウンタイムを抱えていますが、それは常にDNSですよね。ダウンタイムが単一のマシン・グループやアベイラビリティ・ゾーンであることを祈ります。最悪のシナリオは、あるタイプのすべてのサービスに影響を与えるグローバルなイベントによるシステム・ダウンタイムです。

2021年3月15日、MicrosoftはAzureだけでなく、Office、Teams、Xbox Liveなどのサービスに影響を与える14時間のダウンタイムを発生させました。原因は単純で、認証システム内の暗号化キーを更新していたところ、「回転させるな」と書かれた1つのキー(つまり、よくある「触るな!」と書かれた電灯のスイッチに貼られたポストイットのようなもの)が、不運にも回転してしまったのです。

さらに4月には、複数のAzureリージョンでDNSに障害が発生し、その影響で問題が発生しました(DNSがないと、通常は名前を指定してサービスにアクセスすることができないため、DNSの障害はとても被害の大きい者です)。

さて、ここでAWSは美徳の模範ではありません。彼らのステータスボードは、最も深刻なダウンタイムの間でも緑のライトが点灯していることで有名です。しかし、一般的に彼らの爆発範囲は抑えられており、これほど広範囲に及ぶイベントは発生しない傾向にあります。

しかし、お客様にAzureを販売する際には、一般的にセキュリティや信頼性などを理由にしています。「Microsoftは、あなたのスタッフよりもこのようなものをうまく運用できます」というようなことです。重大なダウンタイムが発生すると、Azureの印象が悪くなり、クラウドの方が優れているという主張が弱くなります。通常、まともな次善策は存在しません(私は「マルチクラウド」という言葉を信じていません)。

結論

私は今はまだAzureを使い続けていますが、これからはAzureを使い続けていくことかどうか分かりません。MicrosoftはAWSに追いつくために多くの製品を追加しようとしているのか、それとも準備が整う前に製品をリリースしているのか。私にはわかりません。Azureは、舞台裏の私たちが知らないところではたくさんの粘着テープで支えられているような感じがしてなりません。

Azureではランダムなエラーが多く発生します。Code Functionsは再デプロイされるまでランダムに起動しませんし、Oryxにプッシュされたビルドは常に正常に完了するとは限りません。他にあるようなロバスト性はありません。ポータルも使うのが面倒ですが、AWSも大したことはありません。

Microsoftには、セキュリティと可用性の両方について、真剣にエンジニアリングする時間を取ってほしいと思います。また、Azureが開発者の期待に応え、ドキュメントに記載されているすべてのユースケースが一貫して機能することを期待しています。Microsoftはこれからどうするつもりなのでしょうか?

appstore
googleplay
会員登録

会員登録して、もっと便利に利用しよう

  • 1.

    記事をストックできる
    気になる記事をピックして、いつでも読み返すことができます。
  • 2.

    新着ニュースをカスタマイズできます
    好きなニュースフィードをフォローすると、新着ニュースが受け取れます。