インフラ・サーバ技術の days of future past

26
インフラ・サーバ技術の Days of Future Past @srockstyle

Upload: shohei-kobayashi

Post on 27-Jun-2015

544 views

Category:

Internet


3 download

DESCRIPTION

インフラ・サーバをクラウドでやるようになって、考えをまとめたのを社内LTで発表したやつ。

TRANSCRIPT

Page 1: インフラ・サーバ技術の Days of Future Past

インフラ・サーバ技術の Days of Future Past

@srockstyle

Page 2: インフラ・サーバ技術の Days of Future Past

はじめに サーバリソースを手にいれるにはどうするか?

Page 3: インフラ・サーバ技術の Days of Future Past

クラウド? 物理?

Page 4: インフラ・サーバ技術の Days of Future Past

物理サーバのダメなとこ

• 会社の資産となってしまうので管理が面倒

• その時に予想できる最大アクセス数に耐え切れるサーバ/ネットワークリソースを常に保持しなければならない

• CPUやハードウェアリソースの進歩に物理サーバの減価償却の年月が追いつかない

Page 5: インフラ・サーバ技術の Days of Future Past

クラウドの良いところ

• 重量課金制なので資産扱いしなくていい

• ハードウェアの進歩にいち早く追従できる

• アクセスが少ないときは少ないリソースで、アクセスが多いときは多いリソースに変更などを柔軟に一瞬で可能にできる。

Page 6: インフラ・サーバ技術の Days of Future Past

例:CPU in Amazon EC2

• T2 : 2.5 GHz & 3.3 GHz Turbo Boost

• M3 : Intel Xeon E5-2670 v2 (Ivy Bridge)

• C3 : Intel Xeon E5-2680 v2 (Ivy Bridge)

• R3: Intel Xeon E5-2670 v2 (Ivy Bridge)

• G2: Intel Xeon E5-2670 (Sandy Bridge)

Page 7: インフラ・サーバ技術の Days of Future Past

*** Bridgeって?

• *** Bridgeマイクロアーキテクチャの意味

• コアプロセッサーの世代とかを表す製品名。

• Turbo Boost が基本有効

• →ある程度CPUが辛くなると発熱の余裕をみてクロック数をダイナミックにあげる機能

Page 8: インフラ・サーバ技術の Days of Future Past

Intel CPUの製品発表日

Ivy Bridge : 2012 / 4 / 24

Sandy Bridge : 2011 / 1 / 5

Page 9: インフラ・サーバ技術の Days of Future Past

 物理サーバ買うと・・・

• 前職では大体5年くらいかけて原価償却してた

• 五年前だと2009年。確かCore 2 Duoとかが平気でサーバに使われてた感じ。

• 新しいCPUがでても古いサーバを動かさなければならない(資産なので捨てられない

Page 10: インフラ・サーバ技術の Days of Future Past

時代は物理→クラウドコンピューティングへ

Page 11: インフラ・サーバ技術の Days of Future Past

クラウドになりいままでと変わったこと

• 古いサーバをすぐ捨てられる

• 最適なリソースをいつでも好きなときに使える

• APIが用意され、サーバ・インフラをコードで操作できる

• 手軽にサーバ・インフラの経験を積むことができる

• インフラ・サーバエンジニアもプログラミング能力必須

Page 12: インフラ・サーバ技術の Days of Future Past

クラウドになっても変わらないこと

• サーバミドルウェア / ネットワークの知識は必要

• 大規模サービスをスケールさせる構成構築の知識は必要

• カーネルパラメータチューニングの知識は必須

• シェル&コマンドラインの使い方は必須

• 新技術をワクワクして使える心は必須←一番大事

Page 13: インフラ・サーバ技術の Days of Future Past

開発スタイルの変化

Page 14: インフラ・サーバ技術の Days of Future Past

Dev / OpsからDevOpsへ

• プログラマーとインフラエンジニアという区別がなくなり、障害やデプロイについて一括してみることが多くなった

• 「そこはプログラマーの仕事だから」「そこはインフラの仕事でしょ」が通用しない時代になった

• できる人は割と早くからこういうことやってた

Page 15: インフラ・サーバ技術の Days of Future Past

これからを考えるときに 大事な事

Page 16: インフラ・サーバ技術の Days of Future Past

構成作るとき必要な考える事

• 負荷分散方法は?

• デプロイは?

• 提供するサービスはどういうもの?

• サービスのデータをどう扱うの?

• フレームワークは? 言語は?

Page 17: インフラ・サーバ技術の Days of Future Past

そんなことより楽しようぜ

Page 18: インフラ・サーバ技術の Days of Future Past

みんな楽したいよね• インフラエンジニアだって楽したい

• コード書く側だって楽したい

• コードもインフラもやらなきゃでもどっちも楽したい

• 結局は楽したい

Page 19: インフラ・サーバ技術の Days of Future Past

コンテナ単位の仮想化くるよ

• 将来はクラウドコンピューティングの上にコンテナ単位の仮想化を走らせるのがメイン。

• Vagrantみたいにサーバ単位ではなく、もっと細かく、ローカル環境をそのままあげちゃう感じ

Page 20: インフラ・サーバ技術の Days of Future Past

なにがいいの?• アプリ作る側は環境を意識しなくていい

• つくってあげる、終わり。

• インフラ・サーバをみる側はリソース配分だけに気を使っていればいい

• 「ローカルでは動くのに本番では動かない」がなくなる!

Page 21: インフラ・サーバ技術の Days of Future Past

仮想化って言っても結局中身はLinuxサーバ

それでもなっ......!

Page 22: インフラ・サーバ技術の Days of Future Past

セットアップ・ドキュメントはChef

• Rubyコードでサーバの設定を記述できる

• 環境作るときはツールの使い方を覚えていればいい

• 一度書くとその通りに再び作れるので、なんどもやるために一度書くのではなく、ドキュメントを残す意味でコードでサーバ設計を記載する。

Page 23: インフラ・サーバ技術の Days of Future Past

Chef Zero / Chef Server V12

• ローカルで環境セットアップはChef Zeroで。

• リモートで環境セットアップをする場合はChef Server V12で行う。

• Chef Server V12ではサービスごとにレシピ管理できる機能がつくらしいので期待。

Page 24: インフラ・サーバ技術の Days of Future Past

AWSのAPIコントロール

• これはどっかで作ったほうがいい。

• データ集計やインスタンスのオートスケールなど、AWSにあってもまだ未熟なものもあるので、こちらでやるのも全然いい

Page 25: インフラ・サーバ技術の Days of Future Past

結論・大きくなっても物理にはしません!by データセンター行くの大っ嫌いだった元インフラ・サーバエンジニア(30歳 / 独身)

Page 26: インフラ・サーバ技術の Days of Future Past

ご静聴Thank Tou ★