azusatokohaの日記

人生ラバーダッキング会場

どいつもこいつもaaS、aaSですわね!!!!!(インターネットお嬢様)

www.itmedia.co.jp
ママ、どうしておうちにサーバーがあるの?
ママ、どうしておうちにサーバーがあるの?

どうしておうちにサーバーがあるの?じゃないが?一般のご家庭にサーバーはない!(AA略

2008年発売のWindows Home Serverの記事だけど、2021年時点でご家庭用サーバーなんてまったく普及してないんですよね。悲しいことだ。結局のところ、「ご家庭用サーバー」の用途ってプライベートなファイルサーバって感じで、aaSというかオンラインストレージで賄えちゃうんだよな。しかも、ある程度のファイル容量だったら無料で済んだりするし(最近はGoogle Photoあたりから怪しくなりつつあるけど)、ちょっとお金出せば結構な容量が使える。

オンプレって結局、サーバなりNWなりの環境を全て自前で構築しないといけないし、障害が起きたら対応しないといけない。当たり前のことではあるけれども、それが一番面倒くさいんだよな。

アウトソーシング環境構築の話にも通じるんだけど、環境構築とその維持管理ってかなりコストが高いというか。アプリをやりたいのにインフラに工数かけるのって遠回りになっちゃうんだよな。ならIaC+IaaSになびくのは当然というか。ぼくもAWSのEC2で1インスタンス作ってみたんだけど、本当に1クリックで出来ちゃうから困っちゃうね。すると今まで間接コスト的な扱いにもなり得たインフラが実費とワンクリックで構築できちゃう。そりゃ~~~みんなクラウドっちゃうよな。

オンプレであるならば、そのシステムの規模が大きくなれば大きくなるほど構成要素が広がり、複雑怪奇になってくる。最初は1回路1遮断器で組んでた電源が、UPSを入れ、電源を二重化したからUPSも二重になり、自家発を入れ、そこの制御システムも組み、受電も二重化し、A系B系受電を常に分割して考えて電源二重化なら別系受電を必ず入れないといけない……。電源系だけでこれだけあるうえ、パワーサプライユニットが活性交換なら片系に触らず交換できるような配線…、と細かい部分に至るまで冗長設計の意味を考えながら敷いていかないといけない。

じゃあクラウドに載せることでインフラの煩雑さとは一切おさらばできるかって言われるとそうはならなくて、もちろんハード障害とかディスク障害的な部分はクラウドサービス供給者側でコントロールしてくれるけど、冗長設計的な部分、アプリを動作させ続けるためにインフラ設計をしなければならないっていうのは変わらない。

もともとEC2, RDSで月間稼働率 100% は約束されていない。 – AWS東京リージョンの障害についてメモ - Qiita

クラウドサービスを使ったら、常にサービスが同じように使えるなんてことはなくて、AWSのSLA的にもEC2で月間目標稼働率99.99%、一か月720h計算で4mくらいの停止は覚悟しなさいよね、って明記されてるし、インスタンス単体だと時間あたり90%の稼働率を下回った時点で課金しない、てな要件になっている。クラウド銀の弾丸ではないわけだ。

サービスの一時停止は起こるもの。
想定していなかったのなら、想定しなかった方が残念。 – AWS東京リージョンの障害についてメモ - Qiita

だからこそ、AWSならAZなる仕組みが導入されて利用者自身でコストと稼働率を天秤にかけながら設計できるようになっているわけで。オンプレ機器にまつわるような面倒くさい冗長性設計はないけれども、より高次的というか、概念的、設計思想的なレベルでの冗長性に対する判断は失われていない。

品質水準が意識的に制御されていること。(高くても低くてもいい。意図的なら。) – AWS東京リージョンの障害についてメモ - Qiita