ハイブリッドクラウドで変わるインフラストラクチャ設計

Copyright © GREE, Inc. All Rights Reserved.Copyright © GREE, Inc. All Rights Reserved.
ハイブリッドクラウドで変わる
インフラストラクチャ設計
インフラストラクチャ本部データセンターチームマネージャー黒河内倫

Copyright © GREE, Inc. All Rights Reserved.
氏名
黒河内倫（くろこうちおさむ）
所属
グリー株式会社インフラストラクチャ本部
データセンターチームマネージャー
プロフィール
2002年イッツ・コミュニケーションズ株式会社
2006年楽天株式会社ネットワーク構築・運用チーム
2011年グリー株式会社データセンターチーム
自己紹介

会社紹介
従業員数
1,867人（グループ全体・2014年09月末時点）
事業内容
ソーシャルゲーム事業
ソーシャルメディア事業
プラットフォーム事業
広告・アドネットワーク事業
ライセンス&マーチャンダイジング事業
ベンチャーキャピタル事業

1. HybridCloudのモチベーション
2. HybridCloudを選定する上で重視すること
3. HybirdCloudを利用する上での問題
4. グリーの展望
目次

HybridCloudのモチベーション
(OnPremisesの課題と
HybridCloudに期待すること)

現状のシステム設計方針(On Premisesのみ)
システムとして用意する必要があるリソース

現状のシステム設計の問題点
用意したが未利用となっているリソース
ピークでシステムを用意する必要があるため
システムの未利用時間が多くなってしまう

HybridCloudを導入した際のシステム設計
用意したが未利用となっているリソース
HybirdCloudに向けるリソース

ジャスト・イン・タイム
※ToyotaHPより
http://www.toyota.co.jp/jpn/company/vision/production_system/just.html
“必要なものを、必要なときに、必要なだけ”
という考え方がCloudにマッチした

コストの特徴の違い
On Premises
Cloud
最小単位が1年（通常のデータセンター契約）
1時間つかっても1年つかってもコストは同じ
→長期利用するベースのシステムで利用する
最小単位が1時間（クラウド事業者によっては日単位もある）
ただし1年利用した場合は、オンプレミスの方が安価である
→短期利用するシステムで利用する

システム構成の分離
ベースラインのインフラ
定常的に負荷があるシステム → ベースの売り上げのシステム
自社でコントロールしたいシステム → ネットワークTrafficなど
会社として守らなければならない情報 → 会員情報、課金情報など
突発的なインフラ
イベントトラフィックのシステム → 行事、新規リリースなど
ピークトラフィックのシステム → 夜間帯などの繁忙時刻

HybridCloudで展開できる構成
Webアプリケーションの一般的なシステム構成と移設可能なコンポーネント
Proxy
Web
Slave DB Storage
(Hadoop)
KVS
Master DB
Application
Batch
LoadBalancer
Hybrid Cloudとして
利用可能なコンポーネント
↓
スケールアウトが
簡単なコンポーネント

まとめ
OnPremisesの課題とHybridCloudに期待すること
OnPremisesの課題
今まではピーク帯に合わせたインフラ設計が必要であった
1日のうちピーク帯は4-5時間のため、全体としての利用率が低かった
HybridCloudへの期待
必要なリソースを一時的に柔軟に投入/削除をしていきたい
特にスケールアウトできるシステムコンポーネントを
中心に展開していきたい

Hybrid Cloudの選定基準

Hybrid Cloudの特徴
自社システムクラウドシステム
(Private Cloud)
専用線
Private IP Private IP
特徴
Private IP間で通信が可能
そのため既存システムへの変更インパクトが少ない
クラウドシステム側は提供会社に対してPrivateCloudを提供する
例
AWS Direct Connect
Sorftlayer Direct Link

Hybrid Cloudの選定基準
そもそも提供している会社が少ないため選択肢が少ない
日系クラウドではサービスメニュー化している業者はゼロ
接続性
専用線での接続が必要であるため、
専用線が接続可能なデータセンターであること
Secureな接続が担保される
間違って他の業者にRoutingされるようなことがあってはならない
トラブル対応
トラブル発生時の対応の迅速性

HybirdCloudを利用する上での問題

Hybrid Cloudの課題
SLAの違い
(Private Cloud)
専用線
RouterRouterServer Cloud
1つのシステムを複数のインフラストラクチャで賄う必要がある
サービス上低いSLAのインフラストラクチャに合わせて設計せざるえない
※一般的にはクラウドシステムの方がSLAは低い
乗せるサービスのSLAを落とすことが出来るか？

ベースラインの確保
上記図の赤色の部分と灰色の部分を区分けする必要がある
ここの線引きが難しい

ベースラインの確保
そもそもハイブリッドクラウドを利用する目的としては
コスト削減が主な目的になることが多い
そのため、自社システムとハイブリッドクラウドの割り合いについて
どこかしらの損益分解点がある
しかし、Traffic量/Trafficトレンドは毎日違う
毎日、損益分岐点を出し、システムの比率を変えることは難しい

トラブル編
(Private Cloud)
専用線
DC事業者A事業者A DC事業者B 事業者B回線事業者Maker A Maker B
MDF MDF RouterRouterServer Cloud
契約形態
でも、通常のWAN側の回線なども同じ構成では…？

トラブル編(WAN側との違い)
通信遅延がWAN側よりもシビア
遅延が発生した場合、データの整合性が取れなくなる可能性がある
復旧や回復させる作業に工数がかかる
これはネットワークエンジニアでは出来ない
事業者B網内の問題が解決しないことが多い
クラウドなのでVMの動きなどがわからない
クラウド事業者の都合で、急にスペックの悪いホストに
割り当てられたり、違うDCのVMが配属されることもある

グリーの展望

グリーの展望
インフラの設計
ピーク帯での設計が不要になった
クラウドとの付き合い方
もはや“Cloud”と”On Premises”は敵対関係では無くなった
共存していく関係にある
人材の問題
ただ、 “Cloud”も”On Premises”も理解している人間は少ない
全体を通したシステム設計ができる人材が必要とされる

ハイブリッドクラウドで変わるインフラストラクチャ設計

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ハイブリッドクラウドで変わるインフラストラクチャ設計

Similar to ハイブリッドクラウドで変わるインフラストラクチャ設計 (20)

More from gree_tech

More from gree_tech (20)

ハイブリッドクラウドで変わるインフラストラクチャ設計

Editor's Notes