Old typeからのOld typeからのクラウドインフラクラウドインフラGunma.web #45Gunma.web #45@kanayannet@kanayannet
View Slide
近況報告(前座)近況報告(前座)今更ですが...Ruby技術者認定試験 Gold合格
Gold聖闘士になりました。Gold聖闘士になりました。
今のネタが伝わった方は世代がバレry..今のネタが伝わった方は世代がバレry..
前座はここまで前座はここまで
今日のAgenda今日のAgenda前提オンプレの冗長化・高可用性クラウド・インフラだとどう便利？それぞれの特徴(AWS)大事なことまとめ
前提前提
前提前提今回、VPSとクラウドの違いを厳密にはやらないです。VPSも同じような？括りで話します。
前提前提AWS, GCP, Herokuなど絶対主義者ではないです。場合によってはオンプレでも良いと思う。オンプレでも冗長化・耐障害性を考慮できるwebサービスは回る(365日)ダウンタイムをどれだけ少なくできるか？頭の使い所は多い
前提前提規模が大きくなるほど、オンプレの方が単純な費用は安い？人を育てる費用は別途考える必要がある楽天, Hatena, Pixivさんはオンプレクラウドと言っている費用が安いなど、どうしてもフルクラウドできない
オンプレのオンプレの冗長化・高可用性冗長化・高可用性
知ってますか？この仕組みを知ってますか？この仕組みを
DRBDPacemakerVRRPLVS
複数のサーバ間のHDDをリアルタイムにレプリケーション死活監視 ->何かをキックする仮想IPL4の 負荷分散装置
オンプレだとこれらを意識してオンプレだとこれらを意識して365日24時間動き続ける仕組みを作る訳ですね。発電機や無停電装置(UPS)力率計算(突入電流)etc...
人によってですが...人によってですが...覚えたい純粋なコンピュータサイエンスへの興味大変だ(汗)機械・ハードウェアの部分
当然ですが...当然ですが...
育てる側に立つと...育てる側に立つと...引き継ぎかつ受け継がせる事は困難
これらを熟る人は尊敬できます一方で中々できる人(特に継続できる人)が中々いない現状もある
クラウド・インフラだとクラウド・インフラだとどう便利？どう便利？
オンプレ高可用性の専門知識オンプレ高可用性の専門知識「それほど」要らないです。
「それほど」？「それほど」？敢えてこう表現しています。「意識しなくて良い」とは違うよ例ec2 1台 立てれば何もしなくて良いそんな訳ないよね。
高可用性高可用性何か障害があっても、システムの停止時間をなるべく少なくすることを指す。
どうすれば維持できる？どうすれば維持できる？
AWSでの例AWSでの例負荷分散ELB負荷分散する対象のサーバはprivateなネットワーク環境が欲しいVPC
落ちた時に切り替わるようにCloudWatchアラーム(ec2)ECS(コンテナ系)の自動復旧負荷増えて足りなくなったAuto Scalingレプリケーションやダウンをほぼしない系の仕組RDS, S3, etc...
あれ？あれ？気づいた人いますか？
日本語化リプレイ日本語化リプレイ複数のサーバ間のHDDをリアルタイムにレプリケーション死活監視 ->何かをキックする仮想IPL4の負荷分散装置
多少にニュアンスや範囲や解釈の違い多少にニュアンスや範囲や解釈の違いはあるが...はあるが...
意識の仕方が変わっただけ意識の仕方が変わっただけ
ただし...重要ただし...重要
ハード系ハード系OS(Linux系)とハード機器の相性考えなくて良いmiddle wareの構築と↑とのバランスを考えなくて良いましてや発電機なんてもってのほか
冬場は加湿も必要なのよ冬場は加湿も必要なのよ
静電気トラップ静電気トラップ
本編に戻りますm(__)m本編に戻りますm(__)m
それぞれの特徴(AWS)それぞれの特徴(AWS)
LambdaLambda
LambdaLambdaイベントの種類が豊富S3, API Gateway, CloudWatch ...etc使う用途が「これだ！」と解りきっているものは定義しやすい例: S3に写真をアップしたら、縮小版サムネイルも自動作成キックされる回数が読めてるとやり易い無料枠に入る?リクエスト回数 &&メモリ の従量課金
逆に...逆に...まだ要求される仕様がまとまりきってない時はやりずらいかな？結果:キックされる回数、実行時間、メモリともに食いやすいとんでもない請求額これだったら ec2の daemon起動の方が良かった..etc
EC2EC2
EC2EC2自由度が高いOSと スペックを選んで中身は自分(達)で組み上げるVPS相当 ->違いがあるとすれば、他の cloud serviceと連携しやすい部分かな?落ちた時のデータの保証的なものはvpsは自己責任がほとんどですが...実際はRAID構成を組んでるなど「保証はないけど欠損は目立たない」かな？
EC2EC2どんな時に使うと便利そう？
EC2EC2色々模索中の場合色々模索中の場合要求仕様すらよく解ってない時とりあえず進めながら形にしながら...解らない部分を解るようにしながら
不確実性のコーン不確実性のコーンby itmedia:https://blogs.itmedia.co.jp/hideshibamoto/2013/01/post-7a0e.html
形にしないと形にしないとエンジニア以外の人には伝わらないよね？あるある話この前提で色んなcloudサービスを組み込んでしまうと...over specだったりそのcloudサービスに「縛られたり」考え方設計思想IF
ECSECS実行環境をDockerfileで表現できるec2ほどの自由度はないかも?だが、リリース前には「言葉で定義可能」なものになるはずつまり Dockerfileに出来るよね？何をもって「落ちた」とするか？が明確
以下の例以下の例Dockerfile./entrypoint.sh# .....ENTRYPOINT ["./entrypoint.sh"]# ....bundle exec rails s -e production
railsが落ちたらコンテナ落ちたrailsが落ちたらコンテナ落ちたと見なすことが容易に可能ECSは自動でコンテナを再立ち上げ出来る
大事なこと大事なこと
cloudだからって...cloudだからって...高可用性、耐障害性を意識しなくて良いわけじ高可用性、耐障害性を意識しなくて良いわけじゃないゃない
ところでところで
これって何？これって何？高可用性耐障害性
今日初めて知った今日初めて知ったという方は、是非お持ち帰りいただければと...
なぜか？なぜか？覚えるってなに？覚えるってなに？
知識として知っているだけ「既に試して」身につけている状態
全然違う全然違う
自分で調べて自分で実行して自分で検証してTry and Error繰り返して...
まとめまとめCloudインフラは確かに効果はあるハード面、設備面は気にしなくて良い全く冗長化、高可用性、耐障害性を気にしなくて良いわけじゃない適切な構成(アーキテクチャ)は必要初めからがっつりと cloudアーキテクト組みすぎると...後が大変(な場合もある)不確実なものとの向き合い方 ->重要
何が適切か？進めながら「最適解」を探す旅Try and Error反復練習し手応えを掴む感覚に近いかも？
あくまで自分の経験談ですがあくまで自分の経験談ですが
画像は著作権の都合上画像は著作権の都合上資料公開時には...ry資料公開時には...ry
ご清聴ご清聴ありがとうございました！ありがとうございました！
kanayannet
nearme_tech
77web
kinocoboy2
ogiwarat
azukiazusa1
prof18
pocke
headius
ojun9
yumakann
hagatake
mraible
bermonpainter
jlugia
sachag
aleyda
erikaheidi
thekraken
jonrohan
mclloyd
philhawksworth
brianwarren
zenorocha
ufuk