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

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の違い


専用線RouterRouterServer Cloud

1つのシステムを複数のインフラストラクチャで賄う必要がある

サービス上低いSLAのインフラストラクチャに合わせて設計せざるえない※一般的にはクラウドシステムの方がSLAは低い

乗せるサービスのSLAを落とすことが出来るか？



ベースラインの確保

上記図の赤色の部分と灰色の部分を区分けする必要がある

ここの線引きが難しい



ベースラインの確保

そもそもハイブリッドクラウドを利用する目的としては

コスト削減が主な目的になることが多い

そのため、自社システムとハイブリッドクラウドの割り合いについて

どこかしらの損益分解点がある

しかし、Traffic量/Trafficトレンドは毎日違う

毎日、損益分岐点を出し、システムの比率を変えることは難しい



トラブル編


専用線

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”も理解している人間は少ない

全体を通したシステム設計ができる人材が必要とされる

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

Engineering