はじめに
エンジニアとして様々なことを勉強し、今でも勉強中です。
基本的に難しいと感じることばかりで、その原因はなんだろうと考えてみました。
その答えの一つとして「目に見えないから」ではないか？🤔と自分は考えています。
これが何かしら見える形でイメージできたならばわかりやすく腑に落ちるのではないか？ということで記事を書いてみます！
この記事を読む皆様の理解の助けになれば幸いです。
説明対象
今回はAWS EC2を現実世界で説明したいと思います。
カフェを思い浮かべよう
あなたはコーヒーが飲みたいと思い、カフェに入りました。
そしてレジの前に行き、店員にブラックコーヒーを注文します。
注文を受けた店員はあなたから代金を受け取り、あなたに「出来上がりまで少々お待ち下さい」と伝えました。
その後、ブラックコーヒーを作り始めました。
コーヒーができあがりました。
店員はあなたの元にコーヒーを運びます。
あなたは期待通りの商品が届き満足しました。
EC2とは店員である
上の例のなかで店員はあなたに商品を届けるために色々なことをやってくれました。
このようにあなたの要望のために色々やってくれるもの、これがサーバーであり、EC2です！
図解&AWSに置き換え
ここでイラストやを挟みましょう。
あなたと店員はこのようなやりとりをしたはずです。
これをAWSの世界に置き換えるとこうなります。ついでにソフトウェアの用語にも置き換えておきましょう。
やはり店員＝EC2なのです！
オートスケーリング
ここまででEC2=サーバーのイメージがつきました。
それではEC2でよく聞くオートスケーリングも現実世界で説明してみましょう。
お昼時に注文ラッシュが発生！
今例に出しているカフェは普段はそこそこの客足で、店員一人でもまわるような店舗です。
ただ、お昼時になると一気にお客様が来店することがわかっています。
そして今日の昼も案の定たくさんのお客様が来店しました。
しかし、店員は1人。レジの前にはあっという間に長蛇の列ができました。
もうワンオペの限界です。
これではいけません。どうやって対処するのでしょうか・・・
便利なアルバイトを雇おう
一人でお店を回せないのであれば人を雇いたいところですが、そうなると人件費を気にせずにはいられません。
そもそも今まで一人で回していた理由として、忙しいのはお昼時だけであって、他の時間は全く問題ないからです。さらにお昼時であっても雨が降っていれば忙しくない日もあります。
正社員を雇ってしまうと、働いてもらう意味があるのはお昼時だけだし、月給なので働いていなくとも人件費が発生してしまいます。これではコスパが悪いです。
そうやって悩んでいると、一人の学生が現れました。
お店にとって非常にありがたい働き方をしてくれる学生のようです。
なんとこの学生はカフェから徒歩10秒のところに住んでおり、自宅の窓からカフェの客足を確認して、忙しそうだったら飛んできてくれるそうです。
そして忙しくなくなったら勝手に退勤してくれるそうです。
なんとありがたい！人件費は最小限で済みそうです。
オートスケーリングとは便利なアルバイトである
もうお分かりでしょうか。このアルバイトこそがオートスケーリングです！
ただ、現実にはこのようなアルバイトはいないと思います。頑張ってもタイミーなどであらかじめ雇っておくくらいではないでしょうか。
しかし、ソフトウェアの世界ではこのようなことが可能です。
EC2を需要に応じて立ち上げたり落としてみたり自由自在なのです。
人を雇うこととサーバーを雇うことの違いはここにあります。（？）
ロードバランサー
アルバイトによりピーク時の混雑解消は達成できました。お客様を待たせることもなく満足度が高そうです。
しかし、あれ？なにかがおかしいです。店員は2人いるはずなのに片方のレジにのみ長蛇の列ができています。
なるほど、原因が分かりました。お客様は若い学生アルバイト店員の列に並びがちなようです。
よくわかりませんが、若い子が作ったコーヒーは美味しく感じるんでしょうか。
こっちは空いているんだからこっちに並んでくれていいのに！
並び方にルールを決めよう
そんなお客様の行動により発生するはずのない順番待ちが発生しています。
これに対応するためのアイデアを考えました。
それは、次のお客様は、前のお客様が並んだレジとは異なるレジに並ぶこと！です。
今は店員が2人なので、交互に並ぶこと！ということです。
こうすれば店員の負担が均等になって一件落着です。
ロードバランサーとは負荷分散ルールである
オートスケーリングによりただEC2を増やすだけでは一つのEC2に負荷が集中してしまうことがあります。
そこでルールを設定することでリクエストを効率よく処理できる体制を整えます。
ただし、分散ルールの設定には注意が必要です。
例えば、赤い服の方はこちらへ、そうでない方はこちらへと負荷分散をしたとします。
おそらくこれはうまくいきませんね。
状況に応じて適切なルールを設定することが重要です。
備考
この説明はAWS公式トレーニングを参考にしました。
しかし、これはCLF向けでEC2周りのみがショップに置き換えられています。次回の記事からはAWSが説明していないサービスを説明していこうと考えています。
余談
この度ポートフォリオとなるサービスを開発しました🎉
サービス名は「PowerPointChecker」です！
チームでパワーポイント資料を作成するとき
- 資料の内容よりまず見た目が気になる
- 見た目の指摘を受けていつまでも完成しない
- 作成ルールを守れていない資料が提出される
- 作成ルールがわからない
このようなお悩みを解決するサービスが「PowerPointChecker」です！
しかしこの記事公開時点ではα版リリースで、設定できるルールも少なければバグも多々あるかと思います。
すべて無料でご使用いただけますので、是非利用いただきまして様々なご意見をいただきたいです。
ユーザー数の増加が開発の励みになります。