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

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

@srockstyle

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

クラウド？　物理？

物理サーバのダメなとこ

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

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

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

クラウドの良いところ

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

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

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

例：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)

*** Bridgeって？

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

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

• Turbo Boost が基本有効

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

Intel CPUの製品発表日

Ivy Bridge : 2012 / 4 / 24

Sandy Bridge : 2011 / 1 / 5

　物理サーバ買うと・・・

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発スタイルの変化

Dev / OpsからDevOpsへ

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

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

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

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

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

• 負荷分散方法は？

• デプロイは？

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

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

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

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

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

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

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

• 結局は楽したい

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

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

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

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

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

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

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

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

それでもなっ......！

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

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

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

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

Chef Zero / Chef Server V12

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

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

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

AWSのAPIコントロール

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

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

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

ご静聴Thank Tou ★