コモディティサーバ戦略のパラドックス

servers

今さら確認するまでもないが、サービスの成長に合わせてこまめにサーバリソースを追加し、負荷をうまく分散して処理していく戦略がスケールアウトで、図の上がこれを示す。
主に安価なコモディティサーバを使うイメージである。

一方、図の下は、最初から高価で高性能のサーバを買ってしまい、それをぎりぎりまで使い切って、あるタイミングでまた高性能のサーバを追加するイメージである。まぁ、一昔前まで当たり前だと考えられていたアプローチである。

上だと最終的に6台のサーバが、下だと最終的に2台のサーバがある感じである。

図中の青い部分が「買ってしまったけど使っていない」リソースであって、無駄なコストである。

上の方が、青い部分の面積は小さく、無駄なコストを省くことに成功している。スケールアウト戦略を選択する理由にはいくつかあるが、そのうちでポピュラーなものがこの「無駄なコストの削減」である。

しかしこのときサーバ台数は増えてしまっているので、DatadogやMackerelのような「サーバ毎に課金される」サービスを利用する場合には、料金もきれいにスケールしてしまう。

貧者の戦略としてコモディティサーバを選んだのに、価格が高くなってしまうのだ。

でもまぁ、台数が増えたらサーバ管理の手間は増えるから、「サーバ管理を助けるサービス」の使用料が高くなるのは当たり前だよ、って言われると納得するかも…

Advertisements

Deep Learningで人工知能が実現するとかいってる人たち、あるいはそういう見出しの記事を書きたい記者が正座して読むべき記事

Facebookでケンタロさんに教えてもらった記事。
http://spectrum.ieee.org/automaton/robotics/artificial-intelligence/facebook-ai-director-yann-lecun-on-deep-learning

僕も一時期(2014年の12月から2015年の1月)にDeep Learningについてかなり時間をかけて調べてみたけど、結局明らかに達成されていることは「精度の高い教師あり学習ができる」ということであって、人のように抽象化思考を行う何かがそこから発現するとは思えないと考えていた。(フリーソフトではじめる機械学習の、WEKAでのニューラルネットの章で、オートエンコーダーによってコンピュータが自動的に二進数の概念を獲得するところは興奮したけど。)

We had quite a bit of success with this, but in the end, what ended up actually working in practice was good old supervised learning

また、下記の部分などは僕が好きな苫米地氏がずっと前から表明しているのと同一の見解だと思う。

The bottom line is that the brain is much better than our model at doing unsupervised learning. That means that our artificial learning systems are missing some very basic principles of biological learning.

個人的には、人工知能(強いAI)を作るには、「痛み」「快楽」「生」「死」のような生命の根源に直結する概念、欲求を教えないとダメだと思う。痛みや死から逃げるための判定を最優先させる。このときは低い抽象度で。死から遠いところでの活動には、より抽象度の高い学習や判定を行わせていく。


Continuous Deliveryの時代とJava

かつてバージョン管理やCIなどが存在しなかった頃
人々は手作業で(FTPなどを使い)PHPファイルをアップロードすることで、本番環境へデプロイを行っていた

筆者はJavaプログラマだったので
「本番環境でバグが見つかっても、問題のファイルを修正してアップロードすることで、一瞬で修正できる」
というPHPの利点が非常にうらやましかった
Javaだとjarに固めてアプリケーションサーバにFTPで上げて再起動する、みたいな感じで非常に面倒くさかったのだ

しかし時代は経過し、「ユニットテスト等が行われた後でしか本番環境のファイルが変更されるべきではない」という考え方が常識となってきた
こうなると、「手軽にちょちょいと問題を修正する」というPHPの良さは失われることになる

ウェブアプリケーションを構成するファイル群が全体としてバージョン管理され、テストをパスしたファイル群のみが本番環境に到達できるのだ
まぁそれが正解なのだが、ぶっちゃけ、いざというときの俊敏さは失われることになる
PHPを手作業でアップロードしていた時代、ひどい場合には電話で「なんか問題でてるんだけど」という報告を受けてから数十秒で修正が完了していたケースもあるだろう。

そんなわけで、相対的にJavaでもいいかな、という感じになってきた。