四十三庵

蔀の雑記帳

プログラミングを勉強する前に知って欲しいアプリが動く仕組み

大学時代の友達から「プログラミング教えて!」みたいなことを言われたので、
内心やれやれと思いながら、会話をした。
「何をつくりたいの?」
「やっぱスマホアプリとかかなあ」
「ほーん」
「最初は無料でもいいけど、人気出てきたら有料化とかして、こづかい稼ぎしたいかな」
「ほーん」
「コストはなるべくかけたくないけど、ヒットは狙いたいな。SNS機能つけたりしたい」
「ほーん。コストかかるとしたらサーバー借りたりかな」
「え? なんで?」
「え?」 
「アプリつくるのにサーバー要るの?」
「なるほど」
確かにサーバーはなくてもなんとかなる。
なくてもなんとかなるが、彼のイメージしてるような、
ソーシャルにユーザー同士が交流するみたいなアプリを作りたいのであれば、サーバーは必
要となる。

そんなやりとりをきっかけに、
「なんかよくわからんけど、プログラミング覚えて、なんかサービスつくりたいという気持ちがあるよ、けど知識はあんまないよ」という人向けに、
アプリが動くざっくりした仕組みについて書いてみようと思った次第です。

記事の対象とレベル感

・プログラミング初心者を想定。
・わかりやすさ重視
・なるべく具体的に
・けどたとえ話でごまかしたりはあんまりしない
・インフラチックな話になるかも
・スマホアプリを例にして書いているが、基本的にはWEBシステムの設計の説明
・ミドルウェアの話は割愛

なんでサーバーが要るの?

たとえば電卓アプリみたいな単純なアプリだったら、サーバーは要らない。
Facebookとかメルカリとかみたいなアプリを作りたいのであれば、サーバーは必要となる。
何が違うのかというと、スマホ上で処理を完結できるか否かの違いだ。

電卓アプリはスマホ上で入力したデータを、アプリが計算して、結果を表示すれば良い。
それで完結する。
Facebookで友達を探すには、探したい友達の名前を検索窓に入力して、
Facebookのデータセンターにあるデータベースに友達を探しにいって、その結果を表示することになる。
別にFacebookのアプリが、ひたすら自分一人で文章を書いたり、写真を投稿したりして、自分一人が見る仕組みなら、
サーバーがなくてもいけるが、よほどの異常者しかそんなアプリは使わないだろう。

どこぞのIT企業がちゃんと作ったアプリであれば、だいたいは裏でサーバーが動いている。
ユーザーはあまり意識しないので、確かに僕の大学の友人のように、
スマホアプリであればサーバーが要らないと思うのも無理はないのかもしれない。

アプリが動く仕組み(ざっくり)

「プログラミング勉強したい!」と言ったときに、
イメージするのは普段自分が使っているスマホのアプリとか、インターネットのブラウザで動いてるWEBサービスとかだろう。
普通にユーザーとして使う分には、裏側がどうなってるかなんて意識する必要はない。
僕も働き始めるまでは、魔法みたいなもんだと思っていた。
ただ実際は魔法ではないので、裏側には泥臭い世界がある。

その泥臭い世界を、ざっくりとあらわすとこんな感じ。
f:id:st43:20170611170713j:plain
ユーザーは、インターネットブラウザかアプリから、何らかの操作をする。
たとえばGoogle検索をかける場合を考える。
検索した文字列データが、インプットとしてサーバーに送られる。
なんか上手いこと処理される。
ユーザーに対して、検索結果を返す。
それを受け取った、PCなりスマホなりは、結果を表示する。

基本はインプット/アウトプット*1の関係で、アプリの処理は進む。
ユーザーから見ると、自分の端末とサーバーの役割分担はよくわからない。
とりあえずなんか入力したらなんか返ってきた、という風にしか見えない。
ただ開発者になるのであれば、裏の役割分担は把握しておきたい。

アプリが動く仕組み(もう少し詳しく)

「なんか上手いこと処理される」と書いたところを、もう少し詳しく説明したい。
f:id:st43:20170611170720j:plain
これが一般的なWEBシステムの構成の全体図だ。
(スマホアプリもサーバー通信しているのであれば同じ)

ユーザーが直接操作したり、閲覧したりする端末で動く側を、「クライアントサイド」と呼ぶ。
「プログラミングするぞ!」というときにイメージするのは、このクライアントサイドのプログラムだろう。
実際のところ、多くのクライアントサイドのアプリは、ネットワークを通じて、サーバーで処理をさせている。
サーバー上の世界は、クライアントサイドに対して、サーバーサイドと呼ばれる。
サーバーサイドでもプログラムはガリガリ動いている。

クライアントから入ってきたリクエストは、まずWEBサーバーで受け付けられる。
WEBサーバーがやっているのは、HTMLリソースの管理やら、コネクションの管理やらだ。
スマホアプリだとWEBサーバーとは呼ばず、HTTPサーバーとかロードバランサと呼んだり、あんまり存在を意識しないっぽい。
画面を表示するだけでよければ、WEBサーバーが結果を返して終わりだが、
もっと高度な処理をするのであれば、APサーバーにデータを引き渡す。
APサーバーは、サーバーサイドのアプリが動く場所だ。
たとえばGoogle検索をかけたときに、実際に検索処理するプログラムなんかが稼働しているサーバーだ。
一般的な構成であれば、APサーバー上にはデータを置かず、DBサーバーに置く。
アプリは必要になったら、DBサーバーへアクセスに行く。

こんな風に、サーバーサイドでは三つの役割分担が行われて、
互いに必要なときにインプット/アウトプットをやりとりしている。

ハードウェア構成

f:id:st43:20170611170717j:plain
先程の図では、わかりやすさのために、物理的に三つのサーバーがあるような図にした。
しかし実際は、一台の中に三つの役割分担があってもいいし、大規模システムであるなら何十台とサーバーを構えてしまってもいい。
こちらの図は、一つのサーバー上に、WEBサーバー/APサーバー/DBサーバーを構えた図だ。
小さなシステムであれば、一台のサーバーに全部置いてしまっていいだろう。
物理的なサーバーを分割するのは、サーバーのハードウェア障害への備えという意味合いが大きい。
一台のサーバーに全部を置くと、その一台が壊れたときに、全サービス停止となるが、
WEBサーバー×2、APサーバー×2、DBサーバー×2みたいな構成だと、
一台サーバーが飛んでも、サービスは継続できる。

プログラミングするためにはそこまでやらないといけないの?

「プログラミングが!!!!!!!!したい!!!!!!!」みたいなキラキラした気持ちをもった人も、
勉強していくにつれて、高度なことをやるにはサーバーサイドで処理させる必要があると気づき。
しかもそれは非常にとっつきづらいし、サーバー用意するにしても金がかかるということで、
知識的にも金銭的にもハードルが高かった。

けど最近はクラウドがあり、AWSがある。
AWSは重量課金だし、あんまりサーバーサイドの深い知識がなくても、
「こんな構成にしたい!!!」という気持ちがあれば、Amazonのサービスを組み合わせることで、必要なインフラ部分が構築できる。

www.slideshare.net

まとめ

・ユーザーから見えている魔法の世界は無数のサーバーのレスポンスでできている
・アプリに高度な処理させたければサーバーが必要
・サーバーサイドはとっつきづらいが、AWSみたいなサービスを使うとよい

補足:サーバーレスアーキテクチャ

今のところ、「スマホアプリ」と言ったときに想像するようなアプリは、基本的には裏でサーバーを構えている。
しかし、クライアントサイドの性能も上がっているので、
サーバーなくてもいけるんじゃないか?という発想もある。
それがサーバーレスアーキテクチャと呼ばれる設計思想。
サーバーレスアーキテクチャという技術分野についての簡単な調査 - Qiita
↑たとえばここを参照。
昔のCGIの見直しみたいな話で、この設計であればAPサーバーが不要となるので、メンテすべきサーバーそのものがなくなる。
けれどレスポンス速度は、普通にサーバーサイドでやるよりも遅いので、そこが解消できるのか。
(了)

*1:リクエスト/レスポンスと書くほうがそれっぽいけど