PDF版（3.72MB）

クラウドコンピューティングテクノロジー
2. クラウドコンピューティングテクノロジー
第2回クラウドサービス「IIJ GIO」の紹介
昨年からはじまったクラウドサービスIIJ GIOの紹介。
第2回目となる今回は、2014年度のサービス利用状況に加え、
大規模インフラの開発・運用・基盤維持の活動について解説します。
2.1 はじめに
れを重要視し、これまでのマルチキャリアに加え、マルチ
クラウドの提供に向けた整備を行っています。
2.1.1 クラウド市場のトレンド
これまでクラウド市場の成長・拡大を支えてきた、ソーシャ
2.1.2 サービス概況
ルアプリケーションプロバイダなどのネットビジネス向
■ トピックス
けの利用が鈍化し横ばいとなる中、大手企業におけるエン
2015年4月、
「IIJ GIOコンポーネントサービスデータベース
タープライズ利用の増加が鮮明になってきていて、今後も
アドオンインメモリプラットフォーム for SAP HANAⓇ」の
その成長が見込まれています。このように利用傾向が変化す
提供を開始します。これは、クラウド上でSAP社の提供す
る中、クラウドサービスは1社単独で賄うのではなく、マル
るインメモリデータベース、SAP HANAⓇ の本番環境を運
チクラウドサービスとして様々なクラウドとつながる
（＝
用することができるサービスです。既に2014年6月に、事
連携する）ことが重視されつつあります。IIJとしてもこの流
前検証用クラウド環境
「IIJ GIO for SAPソリューション
本番環境をクラウドで。
独SAP社による認定を取得
コンサルティング
・SAPシステムのクラウド化
・SAP HANAへの移行
SAPをクラウド上に実装する
ベストプラクティスを提供
クラウド基盤
SAP HANA活用の最適解を
クラウドで検証・実現
構築・クラウド移行支援
・IIJ GIO VWシリーズ
・SAP HANAクラウドメニュー
監視運用
・構築テンプレート
・各種ソリューション
・監視・運用サービス
・IIJ GIOサポートセンター
3システムランドスケープ
開発
IIJ GIO
検証
PLM
SRM
SCM
CRM
ERP
SAP BW
SAP Business Suite
IIJ GIOコンポーネントサービスデータベース
アドオンインメモリプラットフォーム
Ⓡ
for SAP HANA
SAPシステム監視
インフラ監視
お客様オンプレミス
SAPシステム基盤
図-1 IIJ GIO for SAPソリューション
28
本番
SQL
利用傾向としては、ソーシャルアプリケーションプロバイ
今回はその本番環境向けのサービスになります。IIJは、
「SAP
ダ向けでは、主にフロントエンドのWeb/APサーバとして
Certified in Hosting Services」及び
「SAP Certified in
利用される仮想サーバは毎月目まぐるしい増減を繰り返す
Cloud Services」を取得しており、SAPの本番環境で安心
状況が続く中、主にDBサーバとして利用される物理サーバ
して利用できる高いサービスレベルと、セキュリティを提供
は、単純なローカルHDDやFCストレージのサーバから半導
します。初期投資、運用コストを抑え、経営判断に即応する
体ストレージを搭載した、高いI/Oパフォーマンスをもつ物
システムの迅速な開発・展開を実現します。
理サーバへのシフト・統合が進みました。エンタープライズ
＊1
クラウドコンピューティングテクノロジー
PoC for SAP HANAⓇ（
」図-1）の提供を開始していますが、
向けでは、サーバ台数以上にストレージの伸びが顕著な1年
2015年1月、
「IIJクラウドエクスチェンジサービス for Microsoft
となりました。ストレージ利用量が大幅に伸びたことで、大
Azure」
（図-2）
の提供を開始しました。これはMicrosoft Azure
容量ストレージを必要とするような大手企業の基幹系シス
の閉域網サービス
「ExpressRoute」
を利用したもので、今回
テムのクラウド移行や、クラウド上へ移行したシステムの
IIJが日本初のパートナーして国内に提供します。これまで
本格利用が進んでいることが窺えます。この傾向は2015年
Microsoft Azureとの接続はインターネット経由のみでし
度も継続するものと予想されます。
たが、ExpressRouteによって閉域網での接続が可能となり
ます。このサービスを皮切りに、IIJはマルチクラウドサービ
スの展開を拡大していきます。
2.2 大規模インフラの基盤技術の取り組み
■ サービス設備展開状況と利用傾向
2.2.1 基盤開発
IIJ GIOの2014年度
（2015年3月）の設備展開状況として
■ クラウド基盤の考慮点
は、2013年度末比で物理サーバ台数ベースで約2割、スト
我々はクラウドサービス事業者ですので、ハードウェアに
レージ物理容量ベースで約4割増加する見込みです。
対しては「大量の機器をいかに効率的に運用できるか」とい
Microsoft Azureへのセキュアで高速、安定した通信を実現
IIJクラウドエクスチェンジサービスは、ExpressRouteのネットワークサービスプロバイダ型の閉域接続を提供します。
IIJ GIOプライベートバックボーンサービスを介してAzureとお客様拠点を結ぶ閉域網を構築します。
① ExpressRoute
Microsoft Azure
② IIJクラウドエクスチェンジ
サービス
③ IIJ GIOプライベート
バックボーンサービス
④ IIJプライベートアクセス
サービス
東京/大阪
⑤ 広域ネットワーク
サービス
お客様拠点
閉域網
Microsoft Azure
IIJ GIOコンポーネントサービス
オンプレミス
・低コストかつ短期利用に対応
・柔軟なリソース拡張が可能
・物理専有型サーバリソースやハイエンド
リソースの提供
・ライセンス資産の持込みや個別機器の設
置に対応する柔軟性と信頼性を提供
・個人情報等の機密情報の安全な保管
・基幹系システム資源の活用
利用シーン
・開発環境
・キャンペーンサイト
・検証などの期間限定システム
利用シーン
・基幹/情報系システム
・低遅延高速I/Oを求めるシステム
・社内システムのバックアップやDR
利用シーン
・個人情報など機密データ
・特殊デバイスシステム
・レガシーシステム
図-2 IIJクラウドエクスチェンジサービス for Microsoft Azure
＊1 独SAP社の設定したサービス品質の基準をクリアし、SAP認定クラウドサービスプロバイダ、SAP認定ホスティングサービスプロバイダとして認められた
（認定日：2013/4/18）。
29
クラウドコンピューティングテクノロジー
うことを常に意識しています。ただ、単純に効率化を突き
また、採用するハードウェアについても、ここ数年海外のク
詰めるならハードウェアを均一化することが理想ですが、
ラウドサービス事業者を中心に選択肢の増加がみられます。
IIJ GIOのように多岐に渡るサービスラインナップの網羅と
サーバ分野では、これまでの一般的なサーバベンダー製品を
費用対効果を考慮すると現実的にはまだ難しく、現時点で
購入するほか、台湾を中心としたODM ベンダーに製造を依
は可能な限りの均一化を目指しています。
頼するケースや、
「Open Compute Project（OCP）
」から得
られた知見を製品化したOCP認定サーバも市場に出荷され
例えば、Web系企業やソーシャルアプリケーションプロバイ
始めています。
ダをターゲットとするパブリッククラウド系のIIJ GIOホス
ティングパッケージサービスの基盤では、価格競争の激しい
IIJでは、自社で展開するクラウドサービス「IIJ GIO」のサー
パブリッククラウド領域で戦うため、過剰な冗長構成を排除
ビス基盤として用いるサーバは、一部のサービスを除き
した割り切ったハードウェア構成とOSSを組み合わせて提供
サーバベンダーが提供する汎用IAサーバを主に採用してい
しています。一方、エンタープライズ分野をターゲットとする
ます。もちろん、ODMベンダーのサーバ製品についても評
プライベートクラウド系のIIJ GIOコンポーネントサービスの
価・検証を行っておりますが、サービス基盤としての要件
基盤では、オンプレミスの拡張リソース、もしくはオンプレ
と、調達規模から得られるコストメリットなどを総合的に
ミスからの移行先の受け皿として、オンプレミス同等以上の
比較した結果、現在の我々のクラウドサービスの基盤とし
ハードウェアの冗長性を備えています。また、お客様が連携、
てはサーバベンダー製品が適しているという判断に至って
もしくは持ち込む既存の商用製品との組み合わせが動作保証
います。ただ、今後もこの判断が最適であるとは限りません
されるクラウド基盤が求められるため、それに合わせた商用
ので、市場の変化に迅速に適応できるよう、我々は引き続
製品を組み合わせて提供しています。何より、サービス基盤
き上記サーバベンダー製品、
ODMベンダー製品、OCPサー
の安定化を図るためには、技術リスクの分散が不可欠です。
バなどの動向を追っていきます。
ファームウェアやドライバの不具合リスクをゼロにすること
は不可能ですから、何か不具合が発生した場合の影響範囲を
ソフトウェアに対しては、我々はすべて自分たちで一から
ある程度局所化するには、同一のコンポーネントであっても
作ることは非効率で、ユーザメリットも少ないと考えてい
特定ベンダーの製品で統一することは避けるべきです。つま
ます。商用製品・オープンソースソフトウェア
（OSS）を問
り、技術リスクの分散の観点からはマルチベンダー体制はメ
わず、お客様のニーズを踏まえながら市場に出ている良い
リットになります。また、複数ベンダーの製品を採用しても特
プロダクトを採用し、サービスとして提供できることに価
定ベンダー製品の技術に依存せず、コモディティな技術を意
値があると考えています。ただ、クラウドサービス事業者が
識して採用することで様々なベンダー製品を選択できるよう
求める規模に対応していない場合は作り込みが必要になる
にもなりますし、設備調達において競争原理が働くため、結果
など、市場製品であるが故の苦労も多々あります。また、巷
的に調達コストの削減にも寄与します。コモディティな技術
では2015年7月15日に延長サポートが終了するWindows
を採用することで、デリバリや保守管理といった運用面でも
Server 2003対応が話題になっていますが、商用製品はも
共通の管理ツールで統合管理できるなど、効率化が図れます。
ちろん、OSSであってもサポート終了は常に付きまとう問
題です。この問題について、IIJ GIOではサポート終了予定の
30
技術リスクの分散化と合わせて、均一化に向けては異なる
製品を採用しているサービスの利用ユーザに対して、情報提
サービス基盤同士のベース機材の共通化を施策として推し
供と注意喚起の取り組みを行っています。特に、エンタープ
進めています。これによって、部品を追加・変更するだけで異
ライズ分野をターゲットとするプライベートクラウド系の
なるサービス基盤に流用しやすい状況を作っています。現在
IIJ GIOコンポーネントサービスでは、多数の商用製品を組み
のサービス開発では、特殊な要件がない限りこの共通化の考
合わせたサービスを提供しており、ベンダーごとにサポート
え方がサービス基盤の物理設計に反映されています。共通化
ライフサイクルが定義されています。それらが常に動作保証
によって、各サービス基盤の余剰在庫も共通の在庫プールと
されサポート可能な状態を保てるよう、
「サービスライフサ
見なすことができ、在庫リスクの低減にも貢献しています。
イクル」
という形でサービスごとに各製品のサポートライフ
技術調査のサイクルを常に回しています。更に、報告に基い
ユーザが安心・安全にサービスを継続利用できるよう支援し
た開発現場や経営層からのフィードバックを参考にしなが
ています。ユーザのニーズはただ低コストでサービスを提
ら、見込みのあるものについてはサービス運用に耐えられる
供すれば満たされるというものでもなく、IIJはこのようなと
かを見極めるため、社内での製品検証を行ったりもしてい
ころにも注意を払っています。
ます
（図-4）
。
■ 継続的な技術開発の積み重ね
このように積み重ねた技術ナレッジと会社の事業戦略を踏
基盤開発とは、サービス開発におけるニーズと、蓄積された
まえて、サービス開発チームはサービスを企画・開発し、設
技術開発という2つの作用によって産まれます。特に、サー
計フェーズでは製品検証チームの検証結果を前提とした基
ビス開発のニーズを実現する最適な基盤を開発するために
盤設計をすることで、サービス品質の担保と設計期間の短縮
は、どれだけ日頃から様々な技術開発分野に知見と経験を
の両立を図っています。調査対象は、サーバそのものはもち
もっているかにかかっています
（図-3）
。IIJでは、組織として
ろんのこと、ストレージやネットワークなどのハードウェア
「メーカ各社の製品動向やロードマップなどの情報収集」→
系や、OS やハイパーバイザー、SDNなどのソフトウェア系、
「技術及び取り組み動向の比較/評価」
→
「定期報告」
といった
OpenStack、CloudStackなどの制御系など多岐にわたります。
サービス開発
継続的な取り組み事例としては、ハードウェアではサーバ
クラウドコンピューティングテクノロジー
サイクルを一覧化し、定期的に最新情報に更新することで、
サイドフラッシュやIntelの次世代CPUへの追随が挙げられ
ます。IIJでは新しい製品がリリースされる度にベンダーから
基盤開発
評価機を入手し、世代ごとの性能特性の変化を把握するよう
に努めています。同時に後継機種に変わることによるサー
重要な
ファクター
技術開発
ズな導入に向けた指針を社内に展開しています。比較的新し
い製品や製品サイクルの短い機種であっても、以上のように
図-3 基盤開発のアプローチ
A社
製品動向調査
ロードマップ調査
ビスへの影響や懸念点を洗い出し、サービス環境へのスムー
B社
製品動向調査
ロードマップ調査
C社
製品動向調査
ロードマップ調査
メーカ各社の技術情報
情報収集
情報収集
調査依頼
技術及び動向の比較／評価
製品技術調査とりまとめ
メンバー
インプット
開発メンバー
報告
定期報告
フィードバック
製品検証
現場
経営層
製品検証メンバー
図-4 技術動向調査プロセス
31
クラウドコンピューティングテクノロジー
技術的な追随を継続することで、サービスニーズに応じ迅速
て実施しています。情報収集においては、一般的なセキュリ
に基盤に取り込んで提供することを可能にしています。ソフ
ティ情報は社内の情報共有サイトから日々発信されている
トウェアではマイクロソフトの早期導入プログラム
（TAP）
ほか、サービス基盤に採用している製品やテクノロジーに
への参加が挙げられます。
TAPに参加することで、
Windows
対しては、常に不具合・脆弱性情報をチェックする体制を敷
Serverオペレーティングシステム
（OS）
及びSystem Center
いています。サポートライフサイクルについても同様です。
管理製品の次期バージョンの設計目標、新機能、現行バー
ただ、我々はベンダー情報を鵜呑みにするわけではありま
ジョンからの変更点、及び製品の導入やアップグレードに
せん。本番サービス環境とほぼ同様の検証・ステージング環
ついての理解を深めると共に、IIJがサービス開発要件とし
境を用いて、自社で作り込みした部分を含め既存環境への影
て求める機能リクエストや仕様改善事項をフィードバック
響可否を慎重に検証した上で、サービス基盤の安定運用にお
を行っています。以上の取り組みによって、発売後間もない
いて重要と判断したものを選別して対応しています。なお、
タイミングで新バージョンのOSやハイパーバイザーを基盤
ベンダーが提供している仕組みやツールが大規模インフラ
インフラに取り込んで提供することができ、クラウドサービ
への展開を考慮していることは稀です。多くの場合、ファー
ス事業者としての要望が取り入れられることで、バージョン
ムウェアやパッチは1台1台手順に沿って適用することを前
が上がる度にサービスを意識したダウンタイムの少ない移
提に提供されているため、大量の設備に確実に展開するた
行や運用も可能となります。
めには自動化などの工夫が求められます。こうしてみると、
プロアクティブな保守対応は前項で紹介した技術開発のプ
2.2.2 基盤運用
ロセスと非常によく似ていることが分かります。
「根本原因
基盤開発、技術開発と並び重要なのが
「基盤運用」
です。ここ
対策対応」では、サービスリリース後に発生する基盤インフ
では基盤運用の主な内容である、
「障害・不具合対応などの基
ラ全体に影響を及ぼすような障害への対応です。先にも述べ
盤維持活動」
について紹介します。クラウドサービス事業者
たとおり、我々は前例のない非常に稀なシステム障害に遭
の設備においても、オンプレミスと同様にシステム障害は発
遇する場合があります。前例のない障害であっても、解決す
生します。ただ、我々が遭遇するシステム障害は、リリース
るには障害を再現させる必要があります。再現しないことに
されて間もない新製品などを採用しているわけでもないの
はベンダーサポートでは対策のとりようがありませんので、
にマルチテナント環境として多数のユーザが様々な構成と
先に進みません。ただ、ベンダーサポートでは数台程度の検
使い方をするため、前例のない非常に稀な障害を引き当てる
証機で再現試験をするため、我々が障害事象を伝えても再現
ことがあります。稀な障害であってもその場で済ますような
しないケースがあります。障害の中には発生確率が非常に低
ことはせず、その障害が基盤全体に影響を及ぼすものかどう
く、再現させるために多くの試行回数を積み重ねる必要があ
か調査を行うと同時に、再発時に備えて一定期間の経過観察
るものも存在するからです。そこで、ときにはベンダーのサ
を実施します。障害原因を究明するのは時間とコストがかか
ポートエンジニアに弊社に足を運んでもらい、実際に発生す
りますが、初動対応時の見逃しが大規模障害に繋がるため、
る様子を一緒に確認することで、粘り強く再現試験を継続す
確実な対処法の確立を目指すのが我々の姿勢です。
るようお願いすることもあります。我々の環境で比較的再現
しやすいのは、一般的に10台で100回試行しないと再現しな
■ 障害・不具合対応などによる基盤維持活動
いような障害であっても、我々は大量の設備を活かして様々
基盤維持活動とは、例えば
「プロアクティブな保守対応」
「根本
なパターンを一度に実行できるところにあります。更に、こ
原因への対策・対応」
「リプレイス対応」
などが挙げられます。
れまでの運用経験の中で遭遇した大量の障害事象から、再
現ノウハウを蓄積した弊社のエンジニアが再現試験に取り
32
「プロアクティブな保守対応」
では、サービスリリース後に発
組むのです。我々は、その圧倒的な障害の再現性を基にベン
見された潜在的かつ致命的な不具合事象への予防保守対応
ダーサポートに働きかけ、いち早く改修してもらうことでよ
のほか、ファームウェアやソフトウェアのサポートライフサ
り安定したサービス基盤となるよう、日々尽力しています。
イクルに追随するためのパッチ適用など、万が一の際に適
例えば、過去にサーバ設備を大量導入した際には、導入当初
切なベンダーサポートを受けるための保守対応の一環とし
からNICの疎通障害が頻発したケースがありました。ベン
移行は未サポート、新機種ではそもそも移行機能が存在し
たため、我々は障害事象を分析し、再現手順を確立して障害
ない」という八方塞がりの状況でした。その問題の解決に向
が発生する環境とその手順をベンダーサポートへ提示しま
け我々が行ったのは、ハードウェアベンダーとの協業です。
した。すると、ベンダーサポートでも障害事象が確認でき、
ベンダーとの数ヵ月に及ぶ協議を重ねることで、なんとか
数ヵ月後には原因が判明しました。ベンダーサポートでは
現行機種にて異機種間移行ができるよう機能追加の了承を
BIOSやファームウェア、ドライバの更新、設定変更などでき
得ました。更に一歩踏み込み、弊社個別に移行機能を提供し
得る限りの回避手段を提示してくれましたが、結局障害が収
てもらうのではなく、一般提供されているファームウェア
まることはありませんでした。最終的にベンダーが既存NIC
を改修して機能追加してもらうことで、本移行機能の公式
での回避は困難と判断し、抜本的な対策として異なるメーカ
サポートを獲得することも実現しました。しかし、問題はこ
のNICへ交換されることになりました。
れで解決ではありませんでした。更なる課題として、移行作
クラウドコンピューティングテクノロジー
ダーサポートは
「過去に事例がありません」の一点張りだっ
業をするのに1筐体あたり数百コマンドの実行が必要なこ
我々はこのように不具合の再現性を材料に、広範囲に及ぶ
とが判明しました。全台数では数万回に上ります。これを
障害リスクを発見し、取り除くことを日々行っています。そ
手作業で間違いなく実行することは到底不可能なため、新
して、以上のような基盤運用の苦い経験の積み重ねから、今
たに半自動化スクリプトを作成し、移行機能を確実に実行
日では技術リスクの分散はサービス基盤では必要不可欠な
できる仕組みを準備しました。
要件となっています。
以上のケースのように、ハードウェアベンダーと協業し利
「リプレイス対応」では、採用している機器のサポートライ
用者側のニーズを取り込むというのは経験・ノウハウが必
フサイクル切れに伴う、設備更改対応になります。企業の
要な領域です。また、作業の半自動化を含めこのような対
IT システムは、ハードウェアの保守やリースが切れる3 ～
応は利用者としては気づきにくいためあまり目立ちません
5年のサイクルでリプレースされることが一般的です。クラ
が、一顧客単独では得難いものです。このような点も、弊社
ウドサービスを提供する我々サービス事業者であっても、
のようなクラウドサービス事業者を利用する上での1つの
（一部を除き）設備は一般的なITハードウェアベンダーから
利点ではないかと思います。
調達しており、設備の導入時期ごとに各ハードウェアベン
ダーの定める製品ライフサイクルに従い、
（多少の延長など
はあるものの）一定期間でリプレースを求められることに
変わりはありません。例えば、Linuxベースの仮想サーバを
2.3 おわりに
提供するIIJ GIO ホスティングパッケージサービスの基盤で
今回は、
IIJ GIOサービスを支える基盤技術について紹介し
は、拡張ディスクに使用するストレージ機器の保守サポー
ました。サービスを利用するお客様には、普段垣間見えな
ト切れの問題に直面していました。現行のストレージ機器
いサービスの裏側が紹介できたのではないでしょうか。
IIJ
は、メーカーサポート終了とリースアップによる設備更改
GIOでは、引き続き皆さんに安心・安全なクラウドサービ
が必要だったためです。クラウドサービスの基盤に求めら
スが提供できるよう、日々の安定運用と品質の改善に取り
れることは常に
「ダウンタイムゼロの設備更改」ですが、今
組んで参ります。
回のストレージ機器は
「現行機種は異機種間のストレージ
執筆者：
木村真理
（きむらしんり）
IIJ プラットフォーム本部システム基盤技術部部長。IIJのクラウドサービス「IIJ GIO」の前身である「IBPS」のサービスマネージャとして、開発・
運用を担当。その後「IIJ GIO」の企画・構想段階から参画し、現在は「IIJ GIO」のシステム基盤系サービスの開発・運用を担当。
協力:
稲葉毅　IIJ プラットフォーム本部システム基盤技術部
33

Download Report