現実世界から学ぶ効率のいいサーバの使い方
- 2. 名前 : 大西 時雨
職業 : インフラエンジニア
Github : @a4t
Qiita: @shigure_onishi
Twitter : @iwanomoto
最近の活動 : 燻製戦士 (Lv. 3)
自己紹介
- 21. オームの法則
I = V / R
電流 = 電圧 / 抵抗
電流 = 5 / 0.001 = 5000A
LEDの直流順電流は 0.03A
約 16万倍 の電流を流しこんだ
LEDのふっ飛ばし方
最大電流があるから
電力が25000Wにはならないよ！
Editor's Notes
- 現実世界から学ぶ効率のいいサーバの使い方というお題で始めたいと思います。
よろしくお願いします。
えと、今リモートで登壇してます。
ちょっとマイクの都合上、そちらの声が聞こえないことがあると思うので、予めご了承ください。
- まずは自己紹介です。
こんな感じになっていて、アカウントはサービスごとに結構バラバラです。
トピックとしては最近燻製にハマってまして
- こんな感じのステータスになってます。
右上のが初回の燻製で結構焦げつきましたが、左が先週の燻製になります、だいぶ綺麗に仕上がりました
あと右下ですが、ベーコンの開発をしてます。
- まぁそんなことは置いといて、資料70枚になってしまったのでサクサクいきたいと思います。
今日話すことは
最近の活動、コンピュータってなんだろう、
単純なCPUの構造、現実世界に置き換える、最適化
となっています。
- そんなわけで最近の活動です。
- AWSの禁止令を自分に出しました
AWSをそれなりに使えるのが僕の武器でしたが捨てました
一時期はAWSのサービス80%ぐらい触ったことあったのですが、今多分60%ぐらいになってます。
なので、今AWSのこと全然追えてないです。
- かと言ってAWSが嫌いになったわけじゃなくて、単純に情報過多になって追えなくなったから切りました
あとAWSだけじゃなくて最新の技術を追うのも控えてます
- やる気あんのか！ってなると思うんですが、
- やる気あります！
- じゃあ何やってるのって話になると思うんですが、
Linuxカーネルコード読んだり、CPUの作り方とか調べたり、オンプレ環境の運用実績見たりしてます
- なんで直接役に立たないものもの勉強してるの？って話だと思うんですが、
とある人にこんなこと言われました。
これうちのCTOなんですけどね
- 日々負荷と戦ってるエンジニアは毎日頭の中にサーバ構成図思い浮かべてる
- まぁこうなっちゃいまして
- 確かにインフラ構成図思い浮かべることはあるけど毎日は考えないなぁと
- でまぁわからないので聞いてみたわけです
例えば日本の人口って何千万人もいるけどちゃんと運用されてるよね？
これが10億人になってもきっと対応方法は用意されてる、と
これ聞いて僕はほぉーーーーーってなりました
- まぁ伝えたかったことってのは「現実世界にヒントはいっぱいある」ってことでした
- そんなわけで現実世界に近づこうと思い、コンピュータってなんだろうと考え始めました。
- OSってそもそもどうやって動いてるんだっけ？ってなりカーネルコードとか読みました。
正直今もちゃんと理解してるわけじゃないんですが、なんとなく雰囲気はわかりました
サーバって一言で言っても裏で色々動いてることがわかりました。
- けどこれまだソフトウェアで解決してる部分だなと思ったので
次にCPUの創りかたという本を読んでる最中です。
この本読んでるのはいいんですけど、ちょっとショックなことがありまして、まぁこんな感じです。
初音ミクかーってなりました。
男のロマン全否定ですよね。
- まぁそんなわけで今CPUの実装調べてたりしてます
けど電子回路とか全然覚えてなくてLEDのランプを何個かふっ飛ばして若干電気恐怖症です。
- ちなみにLEDランプのふっ飛ばし方しっかり記載しておきました。
この回路組むと5000Aに流れることになって、約16万倍の電流を流し込んでもれなくLEDが破裂します。
- まぁこんなレベルの人間がCPUの実装を調べ始めました
- で、CPUってどんなものなんだっけ？ってなり、なんとなく皆さんの頭の中を図にするとこんな感じなのかなと思ってます。
全てが0と1で動いていて自分の書いたコードは最終的には0と1になって、スイッチがあってーって感じだと思います。
- けどこれちょっと不正解なんです。
- 問題点はここにあります。
- これを物理で考えると、スイッチが切り替わって0V側に接触した時に発生します。
ゴムボールのようにぼよーんってバウンドしてしまうんですね
これは力学からすると絶対発生するものなので、回避不能です。
その結果0Vの信号が3回とか4回発生してしまうわけです。
- 同じようなことって実は凄く身近なところにもあって、
例えばパソコンのキーボードとかもこういった問題があります。
これはソフトウェアで解決していて、判定を遅延したりしてます。
要は人間に最適化されてるわけですね。
- けどCPUはもっと深いレイヤーなのでもうちょっとだけ物理的に解決しなくてはいけないわけです。
- で、コンデンサが出てきたりするんですが、正直この辺り説明するとだいぶ時間かかってしまうので、
コンデンサを使って遅延処理を実現してる程度に覚えておいてください
- 結局何が伝えたいかってところだけ言うとコンピュータって物理的なもので出来ているってことですね
当たり前なんですけど、魔法の箱とかじゃないです。
- あとこれは僕の好きな言葉なんでとりあえず載せておきました、興味あったら後で見てください
- 要約すると、人間のやりたいことを詰め込んだものがロジックで、
実現するために回路を作成しているわけですね。
コンピュータは全てここから始まってます。
- とは言ってもこれが役に立つかって言われると微妙なんですよね
多分仕事には直結しなくて、雑学程度にしか使えないレベルのお話です。
- そんなわけでもう少し身近な話にしたいと思います。
今まで伝えたかったことは、パソコンは魔法の箱じゃないですよってことです。
- 待ち行列理論
- まぁコレ社内にいたら一度は聞いたことあるかもしれませんが、うちのCTOの資料パクりました
- いつも10人並んでいるATMが一台あります、
ここで新たにATMを1台追加すると行列はどうなるでしょうって問題です
- もう答え言っちゃうんですが、だいたい0人に近づいていきます。
- いつも10人並んでるということは常に2人入ってきて、
常に二人出て行くというような感じなってます。
- これが2台になると出て行く人が4人になるので、次第に0人に近づくというわけです。
- これをマルチプロセスモデルの置き換えると、人はアクセス、ATMはプロセスということになります。
- で、ここからは僕の作った資料なんですが、
とは言っても現実はそう甘くないですよね。
これは色で分けてあるんですけど、青がコスト1、緑がコスト2、赤がコスト5になってます。
これは時間が経過するとどういうふうになるかちょっと見ていきます
- これ、青いのがコスト1なので1コマ進みました、下は緑なのでまだ待機中です。
で、これ先に進んでいくんですけど…
- まぁこんな感じに数字増えていきますよね
- で、最終的にこうなっちゃいますよね、何時間待たせるんだよ！って
- じゃあ最適化してみましょう
- サーバを分けるってのが一番簡単な方法です。
- こうやって、そもそも赤いやつを同じ行列に並ばせないようにします。
- そうすると、こんな感じに結構スムーズに進みます
- これ当たり前のようにやってますけど、管理画面を分けるってこういう意味ですね
- これはサーバ費用上がっちゃいますが非常に効果的で、ユーザーの待ち時間が減ります
- で、これを銀行に置き換えてみます。
大体コスト的にこんな感じなのかなぁって思ってるんですが、
青が引き出し、緑が振り込み、赤が口座開設って感じにしました。
銀行に行けば当たり前のように見る光景ですね
- この図のポイントは、口座開設の人は別に怒らないってことです。
口座開設するのに10分待たされてもそこまでストレス貯めませんよね？
けど、ATMで10分待たされると人ってイライラするんですよ
これ、同じようにWebで例えると、動画のダウンロードに5秒かかってもユーザーは遅いと感じないけれども、
Webページ表示するのに5秒かかったら遅いって感じますよね
- これってつまりボトルネックじゃなくなってるんですよ。
ボトルネックが分離されたことによってボトルネックではなくなるケースもあるわけです。
まぁとは言っても早ければ早い方がいいのだけは忘れないようにしてください。
- じゃあもっと具体的なケースを見ていきたいと思います。
これは動画アップロードのケースですね
ロードバランサーがあって後ろに3台APIサーバが並んでます。
赤いやつが動画アップロードですね、
こいつのせいでまたさっきと同じように詰まる可能性があるわけです。
- なので、ちょっと改善パターンを考えました、アップロードサーバを分けました。
アップロードサーバで動画のアップロードをして、
アップロードした動画のURLだけをAPIに投げるという構成です。
- この構成のポイントはAPIのサーバが欲しいものってなんだろうってところです。
APIサーバが欲しいのは動画の内容なんてどうでもよくて、動画のURLが欲しいわけですね。
そのURLをデータベースに書き込みたいだけだと思うんですよ、大体
- で、この構成にすると様々なメリットが出てきます。
まずひとつは、軽い処理のユーザーが待ち時間減るってことです
次にアップロードサーバは回線速度を出すために特化した構成にできます。
APIサーバはCPU特化のマシンを選べたりします。
で、両方備えた環境を全部のサーバに反映すると、これはお金が非常にかかります。
- あとスケールアウトやすいってメリットもあります
上のように急に跳ね上がると無駄にスケールアウトとかしちゃいます。
下みたいにある程度安定していると効果的にスケールアウトできます。
- と、様々なメリットがあるので色々制約とかはあるかもしれませんが、
可能であればこういったものにトライしてみると効率よくサーバを使えます。
- そんなわけでまとめに入っていきたいと思います
- ヒントって身近なところにいっぱい眠ってると思ってます。
僕はこの間バスの運賃の支払いを見てシングルプロセスだなとか考えてました
まぁ普通の人から見たら若干頭おかしい人かもしれませんが…
降りるタイミングで両替とかする人いて完全に詰まってるんですよね
- あと、先人の知恵を借りるのも重要だと思ってます。
自分の悩んでることってもっと深いレイヤーで既に解決されてるかもしれないです。
その解決方法は淘汰されてきてるので、優れてる傾向が多いです。
- そして、クラウドは麻薬だなって思います。
特にAWSは凄く便利で危ないと思ってます、僕が麻薬漬けでした。
困ったらお金で解決ばっかりしてきました
お金使えばそれなりにアクセス捌けるのなんて当たり前なんですよね
- で、最後に物理の法則は変わらないってことです
ツールや言語って流行りとかあってチョコチョコ変わりますよね。
で、常に新しいもの追いかけ続けるのはつらいです。
じゃあ楽をしたい場合どうするかってなると低レイヤーのことを知ると恩恵を受けやすいです。
- そんなわけでご清聴、ありがとうございました。
