地に足がついたクラウドのお話

1netmark.jp all rights reserved

(地に足がついた)

クラウドのお話

馬場俊彰[email protected]


● id: netmarkjp

● 株式会社ハートビーツのCTOですたまにJPUGのお手伝いもしています

● MSP(Management Service Provider)してます

● 24時間有人監視サービスフルマネージドサービス(ハウジング、ホスティング)

● 今：インフラエンジニア前職：JavaでWebシステム開発前々職：インフラエンジニア

● OS(主にLinux(CentOS))、ネットワーク機器、ミドルウェア(ApacheとかRDBMSとか)の設定やチューニング、DNS設定などなどをしてます

誰？


近況

● ThinkITに寄稿しました →サーバー管理者の業務カイゼン術

● 第1回：サーバー管理者の目／管理・監視・アーキテクト● 第4回：1ランク上のサーバー管理者になるためには？

● チューニング・障害対応関係の話が増えてきました

● クラウド関係の話が増えてきました

● 会社で「Amazon EC2 フルサポートパック」をはじめました/w 学びing社、シェイクソウル社


今日のお話

クラウド


今日のお話

バズワード？


今日のお話

イメージ？


今日のお話

http://www.flickr.com/photos/michaelroper/13787146/


今日のお話

http://www.flickr.com/photos/kky/704056791/


地に足をつけて話をしよう！


(やっと)もくじ　　　

● 分類と実装技術について見てみます

● SaaS / PaaS / IaaS● パブリッククラウド / ブライベートクラウド● ハイブリッドクラウド / マルチクラウド● スケールアウトクラウド / スケールインクラウド(サーバクラウド)

● IaaSについて掘り下げてみます


SaaS / PaaS / IaaS


SaaS / PaaS / IaaS

IaaS

PaaS

SaaS

● Software As A Service

● さーす

● Platform As A Service

● ぱーす

● Infrastructure As A Service

● いぁーす、あーす、はーす(HaaS = Host As A Service)


システム階層構造

コロケーション

ネットワーク

ハードウェア

OS

ミドルウェア

アプリケーション実行環境

アプリケーション独自開発や、MovableTypeなどの製品、SugarCRMなどのオープンソースのアプリケーション

Ruby on Rails(Ruby), Struts(Java), Symfony(PHP), django(Python) などのアプリケーション開発言語・実行環境(フレームワーク)

Apache, Tomcat, PostgreSQL, MySQLなどのミドルウェア(アーキテクチャ)

Linux, WindowsなどのOS

PowerEdge, Fortigate, CISCO などのサーバ機器、ネットワーク機器

インターネット接続回線などのネットワーク設備

ラック、電源などの物理的なサーバ格納場所


SaaS / PaaS / IaaS

コロケーション

ネットワーク

ハードウェア

OS

ミドルウェア

アプリケーション実行環境

アプリケーション

IaaS PaaS SaaS

ベンダー

ベンダーベンダー

ユーザ

ユーザ

エンドユーザ


　　　の意味

● 仮想化の分界点

● ベンダー依存のわかれめ● ライフサイクル依存のわかれめ

● 既存技術適用範囲のわかれめ

から上は移動可能から下は交換可能


SaaS / PaaS / IaaS

IaaS

PaaS

SaaS

● ベンダーがアプリケーションまで用意して、ユーザ企業に提供する

● Google Apps, Gmail, salesforce.com, 各種ASPなど

● ベンダーがアプリケーション実行環境まで用意して、ユーザ企業に提供する

● Google App Engine, 各種共有サーバなど

● ベンダーがハードウェアまで用意して、ユーザ企業に提供する

● Amazon EC2, Slicehost, 各種VPSなど


SaaS / PaaS / IaaS

IaaS

PaaS

SaaS

サービス提供形態での分類


パブリッククラウド●

プライベートクラウド


パブリッククラウド

● クラウドを不特定多数と共用する(かもしれない)サービス形態

● マルチテナント形式　と表現したりします

ベンダー

ユーザユーザユーザユーザユーザ

注:一般ユーザではなく、クラウドユーザ(企業)



● クラウドを特定少数で独り占めできるサービス形態

ベンダー

ユーザユーザユーザユーザユーザ

ベンダーベンダー


パブリッククラウド / プライベートクラウド


パブリッククラウド

クラウド基盤の独立性での分類


ハイブリッドクラウド●

マルチクラウド


パブリッククラウド / プライベートクラウド

マルチクラウド

(クラウドで実装された)あるシステムがバックエンドとして複数のクラウドを併用すること

ハイブリッドクラウド

(クラウドで実装された)あるシステムがバックエンドとしてパブリッククラウドと

プライベートクラウドを併用することクラウド

利用形態での分類

一歩間違えると普通のマッシュアップ！？


スケールアウトクラウド●

スケールインクラウド


スケールアウトクラウド / スケールインクラウド

スケールアウトクラウド

● 比較的安価なハードウェアを利用した実装で実現したクラウド

● 安価なIAサーバなどを利用する

● Google Apps, Google App Engine, Gmail, Amazon EC2など


● 高性能なハードウェアを利用した実装で実現したクラウド

● ハイエンドIAサーバ、UNIXサーバ、メインフレーム(IBMのSystem zなど)などを利用する

● salesforce.comなど


スケールアウトクラウド(1/4)

Googleの例

● GFS(分散ファイルシステム)

● BigTable(分散ストレージシステム)

● Chubby(分散ロックシステム)

● MapReduce

● Google Cluster

http://www.flickr.com/photos/10900132@N02/2040385439



特徴

● ミドルウェア・アプリケーション実行環境の層でスケールアウトを実現

● MapReduce + GFS, BigTable● Chubby

● 超分散環境を実現するための技術開発



● Google Cluster

● 安価なIAサーバで構築● コンテナ・モジュラー型

– 多少壊れても放置● 革新的な運用

– iDCを冷やさない。熱くなったらセンターごと停止



ナイショだそうです。。[出典]http://developer.amazonwebservices.com/connect/thread.jspa?messageID=49701&#49701

Amazon EC2の例


スケールインクラウド(1/2)

salesforce.comの例

● NETWORK

● Cisco switch, router● Juniper Netscreen Firewall● F5 BIG-IP

● WEB / AP

● Array of dual processor Intel servers running Linux ● Resin

● Search

● Array of Sun servers● Apache/Jakarta Lucene


スケールインクラウド(2/2)

● DB

● Clustered Sun E25Ks● Oracle 9i RAC EE● SunCluster

● Storage: Sun / HDS 9990 Lighting

● Stroage Management: Hitachi Data Systems

● Backup Software: Veritas

● Tape Archive: Sun / Storage Tek

● OS: Sun Solaris, Redhat Linux[出典] http://www.slideshare.net/dreamforce2006/trusted-reliability-performance-with-the-appexchange-platform

コレはスゴい！(後で紹介します)


Sun E25K

● プロセッサ: Superscalar SPARC® Version 9

● CPU/メモリ・ボード: 最大18枚

● 搭載CPU(ボードあたり): 4個● 搭載メモリ(ボードあたり最大): 64GB

● 寸法 (突起物を含まず)と重量

● 幅 /奥行 /高さ /重量● 84.6cm /163.8cm /191.8cm /1,317.27kg

[出典]http://jp.sun.com/products/catalog/pdf/sunfiree25k.pdf


スケールアウトクラウド / スケールインクラウド


スケールアウトクラウド

クラウド実装形態での分類

注：あくまで実装形態での分類(スケールアウトクラウドのPaaSは、ユーザから見るとスケールアップすることもある)


利用例

● IaaS + プライベートクラウド + スケールインクラウド

➔サーバ仮想化を利用した物理サーバ統合

● SaaS + パブリッククラウド + スケールアウトクラウド

➔twitter

● PaaS + パブリッククラウド + スケールアウトクラウド

➔Google App Engine


SaaS / PaaS / IaaS(ふたたび)


SaaS

● ベンダーとの分界点がない

● ベンダーを信頼するしかない(信頼できるところを使う)● 利用方法はベンダーに追従する● ライフサイクルもベンダーに追従する● ベンダーの交換(データ移行など)が不可能な可能性あり● 今までのASPと同じ

● ベンダーとして作るとき

● いままでのノウハウ、考え方をベースに作れる● 信頼性・可用性などは、アーキテクチャを絡めて作り込む


PaaS(1/2)

● ベンダーとの分界点はアプリケーション

● プラットフォームはベンダーに依存する● ライフサイクルもベンダーに追従する● ベンダーの交換(データ移行など)が不可能な可能性あり● ベンダーを信頼するしかない(信頼できるところを使う)


PaaS(2/2)

● ユーザとして使うとき

● ベンダー側バージョンアップ・仕様変更の影響をモロに受ける● ベンダーとして作るとき

● いままでのノウハウも使う● スケールアウトにするか、スケールインにするか● スケールアウトの場合、突き抜けた分散システムを作り込む必要

あり(例: google)● パブリッククラウドとの互換性を持たせるか？

– AppScale, Hadoop● スケールインの場合、拡張方式をあらかじめ考えておく

– ファーミング(垂直分割)など


IaaS(1/3)

● ベンダーとの分界点はOS

● ハードウェア性能はベンダーに追従する● ハードウェア信頼性はベンダーに依存する● ライフサイクルはかなり独立性が高い

– OSレベルで差分をある程度吸収できる● ベンダーの交換(データ移行など)が比較的容易● 環境選定の自由度が高い


IaaS(2/3)

● ユーザとして使うとき

● OS～の管理を自分で実施する必要あり

– 統合管理・統合監視のニーズもきっとある● スケールアウトはアーキテクチャレベルで実装

– 中央管理したらいいのでは– むしろ自動で →Wakameなど

● 冗長化・負荷分散などの非機能要件は自分で工夫して実現● ベンダーごとの利用ノウハウが必要

– Amazon EC2特有のノウハウ– アカウントごとの制約、センター配置など

● いままでのノウハウも使える(使う)


IaaS(3/3)

● ベンダーとして作るとき

● スケールアウトにするかスケールインにするか

・・・・・・・・

ちょっと面白そうなので、ちゃんと考えてみよう


IaaSできるかな(1/9)

材料

● インターネット回線 N本

● リアルサーバ M台

● HUB たくさん

● LANケーブルたくさん

Router Server

Router Server

Router Server

Server

Server

Server

Server

Server

Router Server


宿命

＜


リアルサーバのマシンパワー

仮想サーバのマシンパワー


宿命(その2)

＜


リアルサーバのディスク容量

1台で利用できるディスク容量


宿命(その3)

＜


ネットワーク1本の帯域

1台で利用できるネットワーク帯域



利用機器選定

● Amazon EC2 1インスタンス(程度)をベースに考えてみる

➔1インスタンス＝CPU: 2core 2GHz, Memory: 2GB程度

➔1インスタンス＝1am(アマゾン)という単位で表現してみます

● small IAサーバ(1U) ～15万円(Quadx1, 8GB) 2～4am

● middle IAサーバ(1U) ～30万円(Quadx2, 16GB) 8am

● high IA/UNIXサーバ(4U) ～200万円(Quadx4, 64GB) 32am

● main frame(箪笥) 数千万円～ 128am～



利用機器選定のポイント

● どの程度のマシンパワーが必要か？

● リアルサーバを占有されるとクラウド化の効果が薄い● 初期費用をかけるか？

● 機器としてはmiddle IA以上が現実的● 数の経済を適用できるか？

● ムーアの法則の恩恵を受けるか？

● 個々の機器が高すぎると、恩恵を受けづらい● 管理しきれるか？

● 数・ノウハウ・共通化(Amazon EC2はAPI形式)



永続データ(特にディスクイメージ)の保管場所の設計

● ユーザが都度upload？

● クラウド側に保存？

● 各サーバを分散ストレージとして利用？● 集約する？

– 集約するなら、容量の拡張は柔軟にしたい



実装技術

● サーバ仮想化

● VMware, Xen, KVM, OpenVZ, Hyper-V, Jail, SolarisContainer(Solaris Zone, Solaris Resource Manager), Eucalyptus

● VMware Console, Xen Center, Karesansui ● NAT

● ダイナミックDNS

● Global用 / LAN用● ルーティング・トランキング

(ネットワーク的な負荷分散やスケールアップ)



● 分散ストレージ

● GlusterFS● GFS(Global File System) ※ ≠Google File System

● 柔軟なストレージ

● LVM● ZFS


誰か

できたら教えてくださいm(_ _)m


おまけ


クラウド利用時の注意点

● やっぱり物理的な配置は大事

● パフォーマンスの問題 →割となんとかなる

– 重い処理は一時的に並列度をあげて分散する– 重いデータはユーザの近くに置く(特にEC2の場合)

● 法律の問題 →なんともならない！

– 現地当局にデータを押収・閲覧される可能性● 「そのクラウド」の使い方のノウハウが必要

● クラウドのアカウント単位の制約(最大インスタンス数など)


PaaSできるかな

● Google互換

● AppScale● 独自で作るなら？

● kumofs● Hadoop

● MogileFS

● Lustre

● Roma(楽天)

● プログラム実行基盤・・・何かあるかな？

mixiアプリはPaaSですね。


ご清聴いただきありがとうございました

ばば

地に足がついたクラウドのお話

Technology

rights reserved

service

iaas

paas

salesforce

http

64gb

flickr