よもやま話など
ytnobodyです。実に3か月ぶりの更新です。ご無沙汰しております。
最近はPerlやサーバサイド、クラウドなどについて、個人的にこれといって真新しいとかすごい、と感じたものがあまりなく、そのため更新が滞っておりました。
また、私の主業務におけるiOSアプリ開発の割合が非常に高くなっており、そちら側のキャッチアップにエネルギーを注ぎまくっている状況でして、これがまた楽しくて楽しくて。
・・・というような事情で、なかなかこちらにはアウトプットできていませんでした。
今日はそんな状況を顧みて、「じゃあ自分がいまどういう哲学に基づいて設計・開発などを行っているかをひけらかしてみたらどうだろうか？」と思い立ち、キーボードをたたいている次第です。
もはや当たり前、と思われる方もおられるかもしれません。まぁしかし、個人のブログですし、お目こぼしくださると幸甚です。
本題
さて、webアプリを公開するにあたって、いくつか「最低限これは必要だよね」というものがあると思います。私の場合、7年ほど前であれば以下のものを挙げたことでしょう。
- ドメイン名
- ネームサーバ（とりあえず外部のやつでもよい）
- webサーバ（もしくはVM）
- ネットワークおよび構成機器（ルータだとかスイッチだとか）
- OS（UbuntuとかCentOSとか）
- httpd（ApacheとかNginxとか）
- プログラミング言語の動作環境（perlだとかphpだとかrubyだとか）
- デプロイ手段（capistranoとかansibleとかftpとかscpとか）
ここでは「最低限」なので、DBは割愛しました。しかし、こうして見てみると結構多いですね。
では現在はどうかというと、以下のものを挙げます。
- ドメイン名
- DNS as a Service（Amazon Route53だとかGoogle Cloud DNSだとかAzure DNSだとか）
- Platform as a Service（Amazon Elastic BeanstalkだとかGoogle Apps EngineだとかAzure Web Appsだとか）
- git
だいぶ少なくなりました。減ったものについて着眼していきます。
ネームサーバ
DNS as a Serviceに取って代わられました。
DNS as a Serviceを利用するにも相変わらずネームサーバの知識は必要なのですが、物理的にサーバを用意したりする必要がなく、クラウドプラットフォームへのログインが可能な状況であれば、いつでもリソースレコードの修正や追加が可能となりました。
webサーバ
Platform as a Serviceに取って代わられました。
これにより、VMや物理サーバの運用をする必要がなくなりました。概念的にはサーバがなくなったことになります。
ネットワークおよび構成機器
概念的にサーバがなくなってしまったことによって、ネットワークとその構成機器もまた概念的に不要となりました。
従来これらが賄っていたことはPlatform as a Serviceの一機能として提供されているか、あるいはLoad Balancer as aa Serviceによって代替できるため、必要があればLoad Balancer as a Serviceを追加する程度です。
OS
概念的にサーバがなくなっていますので、OSも概念的に不要となりました。
これはPlatform as a ServiceによってOSが自動的に提供され、かつ更新が行われるようになったためです。
httpd
これもPlatform as a Serviceによって不要となりました。
ApacheやNginxなどの複雑なconfigを書く必要がなくなり、PaaS側に組み込まれた機能によって代替できるためです。
プログラミング言語の動作環境
Platform as a Serviceに組み込まれているもので十分なので、自分で用意することはやめました。
最近はPHP7に寄せておりますが、JavaやC#、pythonなどもよさそうだと感じます。
デプロイ手段
デプロイ手段を自前で用意するのもやめました。
Platform as a Serviceがgitに対応しており、tagを切ることでデプロイが行われるように設定しました。
やめたことで得られたもの
OSやその下位レイヤであるVM/サーバの管理から解放された
PaaSを使う主目的の一つとしてあげられるメリットですが、その大きさは想定以上でした。
思えば、私が過去にやってきた業務の半分近くが、VM/サーバの管理やOSの管理だったという時期があったくらいですから、従来の半分強のエネルギーで業務が回るようになったと言えます。
ネットワークの管理から解放された
OSやVM/サーバもそうなんですけど、一からネットワークを構築して運用することは、それだけで一つの仕事として成り立つくらいに高度かつエネルギーや時間を使う行為です。
また、ネットワークで問題が発生した時には、そのトラブルシュートに必要な知識は専門性が高く、エンジニアのジョブセキュリティが高まってしまいます。そのため、ひとたび問題が発生すると、解決までは帰宅できないという事態が発生します。
OS、VM、ネットワークの管理から解放されるということはつまり、「エンジニアでありながらも、いつも定時で帰宅しプライベートを満喫できる」という状況が、確固たるものになるということではないでしょうか。
httpdの設定から解放された
httpdの設定は一箇所間違うと、サイト全体に致命的な影響を及ぼすことがあります。ネットワークの問題にも性質が似ているのですが、基本的には「解決しないと帰れない」を生み出す可能性を内包しております。
また、OS同様にセキュリティ上の問題が発見された場合、その対応をするのはhttpdを管理している人間が担当することになります。
これらの管理コストをPaaSに代替させることで、利用料金という形であらかじめ解決しておくことができるのは、不確定要素を予定調和化する上で良い判断だったと考えます。
プログラム動作環境・デプロイ手段の整備から解放された
プログラム動作環境の構築やデプロイをAnsibleなどの構成管理ツールで対応することは、もう3年以上前には行われていたことですが、playbookの作成と管理に心理的コストがかかることをずっと気にしていました。
ところがPaaSを使うことで、プログラム動作環境は毎回お仕着せのものが降って来ますし、デプロイについてはgitレポジトリの特定ブランチにpushするか、tagを切ることで実施されるようになりました。
結果、playbookの管理にかかる心理コストがなくなり、「デプロイをするぞ」という意識から、「pushするぞ」「tag切るぞ」という意識へと移ろい、「デプロイをする」という作業自体がなくなりました。
負荷をあまり気にしなくなった
完全に気にしなくなる状況には至っていないのですが、それでもVMを自分で管理するのに比べて、オートスケール機能が設定されたPaaSの場合は負荷に対する心理的コストが圧倒的に低いと感じます。
手が空いた分iOSアプリの開発ができるようになった
もともと私はサーバサイドアプリ(要はwebアプリ）がメインで、インフラを少々嗜む程度のスキルセットでしたが、新しいスキルを習得する余力ができたのは、明らかに従来の業務遂行に必要な時間やエネルギーが半減したからだと考えます。
得られたものから考える
ここまで書いてきたことは、唯一の判断基準「手間・管理の削減」を突き詰めた結果です。
httpdの項目でも書いた「不確定要素を予定調和化する」ということは、手間・管理を削減するうえでキーとなる考え方ではないでしょうか。
歴史を見ると、「速く快適に移動する方法」として馬や馬車、人力車などが広く利用されていた時代がありました。ところが時代が進むにつれ、馬も馬車も人力車も利用シーンが激減するのですが、その一番の理由は「自動車の普及」でした。
「webアプリを公開する方法」という本質だけを見た時に、歴史や得られたものから考えると、何がより進化したものなのかを思わずにはいられないものです。そして、進化したものはいつも「斬新」で「ミニマリズム」であると、私は考えます。