皆さん、こんにちは。ネットアップの方のと申します。本日のセッションは、ネットアップの方のとヤフジャパンのまさきさんと一緒にセッションを進めさせていただきたいと思います。まず、スピーカーの紹介です。私から、ヤフジャパンのストレージのエンジニアをしております、まさきと申します。入社1年目に社内のアプライアンスストレージを運用するチームに配属されました。そこでは、主にストレージ機器のオペレーションと、あとはネットアップ製ストレージの新コンポーネントやOSの検証などを行っていました。そして、去年のちょうど今頃にプライベートクラウドチームに移動になりました。ですので、オープンスタックに関わってちょうど1年になります。現在は、プライベートクラウドチームにてストレージコンポーネントのバックエンドで使用するストレージの検証や選定、そして、オープンスタックのシンダー、スイフトなどの開発運用を担当しております。はい、ネットアップの方のです。普段は通信キャリアのお客様ですとか、サービスプロパイダーのお客様、そして、ヤフージャパンの皆様を担当しているプリセールスのエスインになります。このセッションに関しましては、コミュニティのセッションという形ではあるんですけども、ヤフーさんの環境でネットアップのスレージ、いろいろお使いいただいていまして、やっぱり大規模の環境になればなるほどいろいろな考慮時効がありますので、そういったところの検討ポイントであったりですとか、ネットアップ使っていなくても、お役立ていただけるような内容を2人で一緒にお伝えできればなという形で考えております。本日のアジェンダーなんですけども、まずヤフージャパンでなぜオープンスタックを導入して、そして今どのように活用されているのかというところを、まさきさんの方からお話いただきます。その中で主にストレージの考慮ポイントについて紹介いただいた後に、私の方からオープンスタック環境でストレージ、主にシンダーの環境で考えられる要件、そして考慮時効といったところをお話をさせていただきたいなと思っております。それではまさきさんよろしくお願いいたします。では私からヤフーにおけるオープンスタック環境の取組みについてお話しさせていただきます。ご存知のとおり、ヤフーはインターネットポータルサイトのみならず、さまざまなサービスを提供しております。これらの環境を迅速に提供し、安定した運用を行うために考慮しているポイントなどを紹介させていただければと思います。まずは導入の経緯について説明させていただきます。オープンスタック導入以前、もともと私たちは社内独自で開発したプライベートクラウド環境を提供しておりました。しかしながらこの環境ではさまざまな問題がありました。一つはAPIのフォーマットが独自のものであったということです。また限られた人数の中でIS環境の開発と運用を同時にすることは難しく、結果的に運用の方に人的リソースを奪われる形になり、きのうの開発は停止してしまいました。リリース人は最新だった機材も時が経つに連れて、さらに性能の優れた機材が登場してきましたが、それらを使用した新しい環境を作ろうにも、また1から作り直すことになり、ライフサイクルが回らないといった問題がありました。そこで2013年の初頭になりまして、オープンソースのオープンスタックとクラウドスタックの2つに着目して検証を開始しました。当時のアジア県ではクラウドスタックの方が人気に側あったのですが、それ以外の地域ではオープンスタックの方が利用される傾向にありました。検証の結果、私たちは自分たちの環境に合わせて追加で開発できる部分や、世界的に見て情報の流通量が多く、欲しい情報が入手しやすいオープンスタックを選択しました。オープンスタックの本格的に検証を始めて、大体半年だったと思うのですが、開発環境としてリリースすることができました。そして、今日で丁度稼働を始めて2年になります。私たちが数あるアイアースのソフトウェアの中からオープンスタックを選択した理由としては、以下のような点が挙げられます。前日でもお話しした通り、世界的に見ると、オープンスタックの進歩と普及速度は見を見張るものがありました。初めの頃は連携するソフトウェアもそれほど多くはなかったのですが、日本にもユーザー界などがありまして、活発にセミナーや勉強会が開催されていました。問題が発生した時も、他社のユーザー、ベンダーとさまざまな人に情報を教えしてもらうことで問題の解決をすることができました。今では、ヤフ・ジャパンは国内最大規模のオープンスタック利用者になっております。また、求める性能や機能によっては、バックエンドで使用するハードウェアが固定される可能性もありますが、そういった点は、ベンダーに頼み専用のドライバーを用意してもらうことで、こちらの負荷を軽減できるといったこともできます。次に、検証から導入までについて話そうかと思います。弊社ではオープンスタックの環境を検証開始してから、約半年で開発環境のリリースをすることができました。この辺りは、もう少し後で詳しく話そうと思うのですが、オープンスタック環境に移行したことで、オープンスタックのAPIを通してデータセンターリソースの操作が可能になりました。また、数十秒で数百規模のインスタンスの起動も可能になっております。そして、開発環境のリリースから、半年後にはプロダクション環境にて環境をリリースすることができました。サービス側の人たちには、開発環境である程度使用間に慣れておりましたので、リリース後数日でサービスとして、本格稼働することができました。このように、短期間で環境リリースすることができるようになったのは、独自のAPIを用意する必要がなくなったのが大きいかもしれないです。以前の全て字枚で用意していた環境ですと、基本機能やあったらいいな程度のマイナー機能、社内のアカウント連動などの独自で用意する必要がある機能など、全て自分たちで構築する必要がありました。ですが、オープンスタックを導入してからは、基本機能や、基本機能はコミュニティで開発されたものを利用すればいいですし、細かな機能、そしてちょっとした要望などのマイナー機能についてはベンダーにお願いしています。基本的に自分たちで用意すればいい部分は、プライベートクラウドのユーザーに向けた社内独自機能の部分の開発だけでよくなりました。最近の取り組みとしては、だいぶ独自機能が開発が完了してきましたので、コミュニティへのコントリビュートに向けた動きも出てきております。こちらのスライドに見せておりますのは、オープンスタック基盤を通してインターネット上にコンテンツを配信している主な6つのサービスになります。ヤフジャパンは100以上のサービスを提供しております。そのほぼすべてでオープンスタック基盤の活用がされております。これらは最近オープンスタックから配信されるようになったものではなくて、どれもすでに1年以上オープンスタック上で稼働しております。これらのサービスが使用しているインスタンスは、向上的に稼働しているものもありますが、例えばオリンピックやサッカーのワールドカップ、選挙などの国民の中国が高くアクセス数が通常より急激に増加されると予想されるものは、一時的にインスタンスの増強を行っております。このような一時的な増強をできるのは、巨大なリソースプールを管理できるオープンスタックの大きな強みだと思っております。今日来ているTシャツにはバックストックと書かれていますが、これは環境の変化やニーズの変化、ビジネスの要求に対してスピードに対応していこうという弊社のスローガンになります。アプリケーションのリソースサイクルやリースサイクルや環境の変化は積極的にされるオープンスタックは、ヤフーのスローガンに非常にマッチしているのではないかと思っております。次にヤフージャパンの利用状況について見てみたいと思います。現在ヤフージャパンでは4000台のコンピュートノードが起動しております。こちらのグラフはユーザーサーベーの結果になりますが、ヤフーはここに分類されております。コンピュートノードのほかにもコア数は96000個、インスタンスについては5000台に上りますが、こちらもサーベーの結果と比較してみると上位の位置に位置していることがわかり、かなり大規模なユーザーであることがわかります。次に弊社のプライベートクラウドサービスの提供状況です。弊社の環境で稼働中のインスタンスは開発環境とプロダクション環境合わせて5万インスタンスほどになります。内役としては開発とプロダクション環境それぞれ半分ずつといった状況です。これらのインスタンスの稼働率は99.996%で、可用性としては十分なレベルを提供できていると思います。現在ではトラフィック密度も物理環境の時と比較して6倍まで成長しております。データ量の操用量は20ペダバイト、提供されているクラスターは約20クラスターになります。この20クラスターというのは流動的でして、閉鎖されているクラスターやまた新しく構築されるクラスターもあり、全体でライフサイクルを回しております。これらのプライベートクラウドを管理しているチームメンバーは創造11人になります。最初からプライベートクラウドチームに所属していたメンバーもおりますが、オープンスタックはネットワークやサーバーまたストレージといったIRSの技術の集合体になりますので、もともとのインフラ技術に関わっていたメンバーも含まれております。また開発担当と運用担当に分かれておりますが、この他にもアプライアンスを運用するメンバーがおります。オープンスタック上のトラブルについては、プライベートクラウドチームが担当しておりますが、実機のトラブルになりますと担当のチームの人たちが動いて対象しております。その辺りは各チームで連携を密にとって対応しております。ユーザーの利用状況です。ヤフジャパンには全てのサービスのエンジニアを合計すると、約2000人程度エンジニアがおります。彼らに対して平等にIRS環境を提供しております。バーチャルマシンで障害が起きたり、パフォーマンスの劣化が起きたりした際は、社内のオープンスタック運用チームが迅速に対応しております。また、プライベートクラウドチームでは、社内向けにIRS環境を普及の一環として、定期的にセミナーを実施しています。最初はエンジニア向けで行っていたのですが、最近では他の職種の人たちも興味を持ち始めて参加するようになりました。そのかやはってかエンジニアでない人たちにも活用が広まっております。1日あたりのインスタンス起動数を見てみますと、およそ500インスタンスが起動しています。ですが、およそ1か月でこのうちの半分は消えていきます。セルフサービス環境ということもあって、ある程度余裕を持ってデプロイして、リリース後、不要になったものは削除されていっているんだと思われます。また、弊社のプライベートクラウド環境では、全て自社運用していることもありまして、パブリッククラウドを使用する場合、よりも大幅にコストカットをすることができました。一般的なスペックだと、そこまで大きなサニアにならないかもしれませんが、サービスが希望するスペックや、2コア12GBが多いのですが、これで計算すると大きな差が出てきております。結果として、パブリッククラウドを使用する場合よりも97%コストカットに成功しております。稼働状況の話のついでもう一つお話ししたいと思います。こちらの写真は、東京にある有名な電波塔の東京タワーです。現在、弊社のオープンスタック環境で使用しているストレージのコンポーネントは、主にシンダーと小規模な水筒になりますが、それぞれの環境のディスクを全て積み上げると、約377メートルになります。これは、東京タワーの333メートルよりも高い計算になります。このスタックを利用することによって得られたメリットについて、以下の内容が挙げられます。まず一つに標準化されたAPIを使用することが可能である点です。標準化されたAPIを使用することで、それを取り巻く多くのOSSを使用することが可能になります。今までは、こういった部分も全て字枚で用意しており、新しいヤース環境の構築や新機能の開発がとどごってしまうことがありましたが、今ではアプリケーションに近いところに人を避けるようになりました。また、これはユーザーにとってもメリットになっておりまして、インターネットにあるナレージを用いて手軽に利用することが可能になりました。二つ目は、ベンダーを意識しないリソースが活用できる点です。オープンスタックはさまざまなベンダーが参加しており、オープンスタックのドライブも多数用意されております。そのため、ハードウェアリソースの選択肢が広がり、ハードウェア部分の中小化が実現できています。三つ目に、データセンターの中小化が上げられます。オープンスタックを導入したことで、サーバーの準備に必要だった発注の日などの時間を削ることができ、物理環境の時に必要だったラック確保、配線、ネットワーク補築などのユーザー側で考慮する必要がなくなりまして、マシンのデプロイが用意になりました。また、バーチャルマシンの提供だけでなく、オーケストレーションによりデプロイも可能な点もオープンスタックを使用することで得られた大きなメリットだと思います。ユーザーへの提供イメージはこのようになります。ユーザーはプライベートクラウドチームで用意したコントロールパーネルを当時してバーチャルマシンの操作を行ってもらっています。基本的にリソース管理は運用側で行い、ユーザー側では機材の剪定や発注といったわずらしい作業から開放させています。ユーザーは用意してあるものからこのようにクラスターがあるデータセンターであったりハイパーバイザーの種類であったりプロダクション化開発化ストレージやネットワークはどうするかなど選択をして使用するだけです。用途に応じてSSDなどのデバイスの希望があればその旨を私たちプライベートクラウドチームまで伝えていただき順次提供を開始しております。クラスターのリソースが減ってきた場合でもそれを問いらせることなく新しいクラスターをリースしております。弊社でユーザーに提供している統合インターフェスがこちらになります。こちらのUIではオープンスタッグの基本的な機能や他にもクラスターことの残存リソース等の統計情報VMの検索機能などがあります。またアベイラビティーゾーンごとに利用状況も確認することが可能です。最初はそれほどバーチャルマシンを必要としない場合でも後々規模を拡大していきしたい場合やディザースタリカバリーを考えて統合にバーチャルマシンを分散させて起動させたい場合などの参考になるかと思います。ユーザーはこちらのUIからバーチャルマシンのデプロイ先のクラスターを選択して起動することが可能です。ちょっと絵が消えていますね。次に弊社で現在使用しているハイパーバイザーの環境について説明したいと思います。まずはKVMの環境についてです。KVMの環境は構築の際にシェフを使用しております。構築するオープンスタックのバージョンごとにレシピを用意しそれぞれに最適した状態で構築を行っております。大きいクラスターですと200を超えるハイパーバイザーのセットアップが必要シェフを使えばコマンド一つでデプロイが可能になります。またKVM環境ではアベイラビティーゾンごとに様々なフレーバーを用意しております。UZAKARAの要望では何アイオプス出したいですとかレイテンシーを抑えたいといった要望が届けられますのでそれに合わせて様々なデバイスを用意しております。SSD機を出したり最近ではNVMEといったものも使用しております。他にもバックエンドで使用するストレージに合わせてそれぞれのストレージのうまみを最大限に引き出せるようにベンダーが提供したシンダードライバーを利用しております。次はVMウェアESXi環境について説明します。最近ではVMウェアのESXを使用した環境もリリースしております。VMウェアではVセンターを使用してVSX環境のESXIの統合管理が可能になります。またVDSを使用すればVMのアクセスをデータセンター単位で切り替えることも可能です。VMウェアの利点の一つとして上調性の高さが上げられます。VMウェアの機能にVMウェアHAというものがありますがインスタンスのオヤサーバーが障害によってダウンしても自動的に復旧できるのでインスタンスのダウンタイムを提言することができます。またVMウェアのプラグインであるVAAIを使用することでバックエンドに使用しているストレージの機能を最大限にガスこともできます。インスタンスのイメージはストレージ側に保存されているため他のインスタンスからの影響を受けてパフォーマンスの低下がするといったことはありません。インスタンスの起動時にもインスタンスの指摘を起動するため不要なトラフィックを削減することができます。それではコンポーネントの選定事故についてお話ししたいと思います。弊社においてストレージのコンポーネントを選定する際に特に気をつけているのが以下の3つになります。1つ目はIoを止めないこと2つ目はインスタンスのクローンにかかる時間3つ目はベンダーのサポートです。Ioを止めないというのはサービスの継続性において非常に重要な要素になります。弊社のサービスの中ではライフラインになるものも含まれておりますのでこの点は大きなポイントです。障害が起きてもフロント側ではサービスを継続し運用側でフェイルオーバーやフェイルバックを駆使して障害の復旧を行います。メンテナースの時も同様です。ローリングアップデートやサービスを継続しながらのアップデートが可能な点を剪定のポイントとして考えております。インスタンスのクローンにかかる時間もストレージを剪定する際に非常に重要な要素の1つにしております。オートスケールをすることを考えるとこの点は考慮せざるを得ないところです。ベンダーのサポートもやはりコンポーネントの剪定の上で大切になってきます。弊社ではさまざまなサービスが混在していることもありたくさんの要望が出てきています。その全てを自分たちで用意するのはとても負荷がかかります。これらの要望をベンダーと相談し協力して実現していけるベンダーを選ぶことも剪定する上でかかすことはできません。弊社の診断の実装については以下の3点が挙げられます。1つはインスタンスのクローン時間の短縮です。バックエンドのストレージには大量のインスタンスを短い時間で起動できるようにクローン技術を対応しているものを使用しております。2つ目はアベイラビティーゾーンごとのストレージの設置です。弊社ではデータセンターに流れる電源系統ごとにアベイラビティーゾーンを分けてハイパーバイザーの設置をしております。それと同様にしてストレージも分けて設置いたします。ユーザーはインスタンス起動時に親ハイパーバイザーのアベイラビティーゾーンを意識してもらいインスタンス同士で上調化するようにしてもらっています。片系の電源系統が何らかの要因によって落ちても別系統の電源系統が生きているため運用の継続は可能です。3つ目はマルチバックエンド構成です。バックエンドで使用するストレージは絞らないようにしております。基本的にはアプライアンス製品のストレージをバックエンドで使用しております。安定度や運用のしやすい点を考慮するとやはりアプライアンスという選択肢になります。しかしソフトウェアデファインドストレージも最近では選択肢の一つに入ってきております。技術の進歩というのもありますし新しい技術をどんどん取り入れていきたいということもあります。最近ではSGSが別のコンポーネントと連携した技術を取り入れてきていますし新しい価値を想像するという点では非常に面白いと思っております。ここまでの説明で弊社のオープンスタック環境においてストレージネットアップを採用している点をお話ししましたがそれでは何で弊社がネットアップをオープンスタック環境に採用したのかお話ししたいと思います。弊社ではもともとオープンスタック以外にもネットアップを大量に利用しておりました。ですのでネットアップに強いエンジニアもおりそういったメンバーのスキルや利用実績も考えた上で選定をいたしました。これはシンダー等のデータを守る必要があるコンポーネントを選ぶ上でやはり重要な要素になります。他にもフレックスクローンなどのネットアップの性能を引き出せるドライバーがあったのも大きいです。これらのドライバーはオープンスタックのAPIを変更せずにフレックスクローンは弊社のような様々なサービスがイヤス環境に混在しておりタイロンサーバーリソースが必要になる場面に非常に有効な技術になります。また仮想環境に移行する際もNFSといった共有ファイルストレージを多く採用しておりその分野に強いネットアップを採用したのは流れだったかもしれません。マニラといった共有ファイルストレージのコンポーネットも非常に魅力的でした。そのために強力的なベンダーのサポートも必要ですし、弊社のような環境で実績を積んでいくことも必要かなと思っております。これを私たちは競争と言っております。それでは競争しているネットアップにオープンスタック環境でのストレージの検討ポイントについてお願いいたします。私からはオープンスタック環境で利用するストレージの考慮ポイントをそちらの解決手段の方をお伝えできればなと思っております。まずオープンスタック環境のストレージ要件、インフラ側面から考える要件とイヤース特有の要件があると考えられます。インフラ側面の考慮試行としてはストレージに求められる一般的な要件であります。障害に対する火用性であったりシンプルな管理性、容量の効率化が挙げられます。加えて例えばモンスターVMが出現したときに他のVMに影響を与えないように防ぐような愛用のコントロールであったりまた、広大なクラウド環境ではデータが集約するストレージになりますので停止はユーザーへのインパクトが非常に大きくなります。障害だけではなくて計画停止のようななかなかコントロールが難しい計画作業に関しても極力停止をせずにユーザーへの影響を抑えるようなそういった機能の取り入れというのが非常に重要になってくるのではないかなというふうに考えられます。それではセルスタービスポータルと入れたときの要件とは何でしょうかまずインフラ側面の要求事項に関しましてはネットアップの場合にはクラウド環境、オプスタック環境で非常に実績のあるネットアップのクラスタドデータンタップと言ったものを利用することで解決することが可能です。一方セルスタービスポータルの環境の要件事項です。まずセルスタービスポータルというものがユーザーにどのように解決されているのかと言ったところを考えてみたいと思います。オープンスタックの利用ユーザーはホライゾンと開放されたセルスタービスポータルからテナントを作成します。テナントに対してはインスタンスやCPUコアスストレージの容量などコートを設けた上でリソースという形で提供されます。このテナントに対するユーザーの作業ですがよくやる作業としてはインスタンスの作成やスナップショットを利用したバックアップそしてテンプレートのアップロードなどが考えられます。これらのタスクというのは今まで仮想化環境というものを運用していたIT部門がコントロールしていた作業になります。例えばバックアップです。バックアップによる交付化というのがシステムに非常に影響を与えると言ったところから他の低い野間体にジョブなどを構成して取得されていたと考えられます。仮想マシンの生成に関しても同様です。数百台規模が仮想マシンが同時に開始した場合にはそれなりのホストへのフカですとかネットワークのフカというのが考えられますのでこういったところを実際に性能としてストレージにオフロードできない場合にはインスタンスの集約密度に非常に大きな影響を与えることになってきます。セルスタービスの環境ではこれらデータ生成における負荷をどのようにコールするかというのが非常に重要な要素になってきます。先ほどお話し通り主なユーザーの作業というのは仮想マシンの復生、スナップショットの利用をしたバックアップ、テンプレートのアップロードです。ストレージの機能と連携させることで仮想マシンの復生に関しては容量を消しせずに瞬時に復生が可能となります。スナップショットを利用したバックアップに関してもデータを生成せずに性能劣化なくバックアップすることが可能になります。そしてホストやネットワークを回収するデータのトラフィックについてもストレージをオフロードすることが可能です。セルスタービス環境のワークローンに対してネットアップの場合には強力なストレージの仮想化機能を連携することでそれらのデータというものをストレージにオフロードしてオプスタックのインフラ全体を効率的に運用することが可能となっております。まずはKVMの環境です。KVMの環境へはネットアップもシンダードライバーを提供しています。ネットアップのUnifiedDriverというものを提供しているのですがこのUnifiedDriverを利用することで先ほど同じようなスナップショットのバックアップやデータテンストのオフロードマシンのクローニングといったところを先ほど同じようなフレックスクローという機能に連携させて利用することが可能になっています。ちょっと時間がないので伸ばしていただきますが次にVMARの環境を考えてみたいと思います。VMARの環境というのはオプスタックでコントロールする場合例えばESXを伸ばとして利用する場合にはVCenterESXドライバーを利用することになります。そしてシンダーの利用に関しましてもVMDKドライバーを利用してインサンスのブートであったり外部ディスクの接続生成を実行することになります。要するにベンダーが提供しているシンダーのドライバーというのが利用できなくなってしまうと言ったところが考えられます。そのため仮想マシンの複製はVCenterを返した複製になりますしVMARのスナップショットになってしまいます。当然トラフィックもオフロードすることができません。またネットアップが提供しているような仮想環境向けのプラグインツールですね。我々の場合にはバージャルストレージコンソールと言った仮想マシンをバックアップする際にネットアップのテクノロジーを利用したバックアップツールなどがあるんですけどもこういったツールも利用することができなくなってしまいます。ではどのように仮想マシンの仮想マシンを喰らうサイズですので試式が可能になってしまいます。このような才能を参加してあげるような新しい仮想マシンの場合などの仮想マシンのスナップショットで専用していこうと言ってものが必要かゲームの仮想マシンの仮想マシンを用意しました。できないサイズの把它変更することが out 用意してインテグレーション内容はネットアップを利用した場合の連携の機能になるんですが例えば仮想マシンの複製ですこれらはNFSVAやVBOLを使うことでフレックスクローンと連携して瞬時にそして容量消費なく複製することが可能になりますVAIでも良いのですがVMD系単位の複製というのをストレッジと連携して実行する場合にはNFSVAを利用するのがお勧めとなっております続いてスナップショットを利用する場合です残念ながらスナップショットに関してはVAIですとかNFSVAで機能を置き換えることができないようになっていますこちらは新しくVSF6からリリースされたVBOLを量を検討するべきですVBOLを使うことでVMのスナップショット自体もフレックスクローンと連携してバックアップが取れるようになっておりますただまだ新しい機能になりますので機能の採用に関しては非常に慎重にならざるを得ないというのが実証ですそして最後にデータ戦争のオフロードですこれらの機能に関してはVAIもしくはNFSVAを利用して解決することが可能になっておりますこのような形でKVMとVSFIAの環境についてお話しさせていただきましたが利用するハイパーバイザーによって利用する技術要素というのが少しずつ変わってくるというところを念頭に置きながら基本的にはそのハイパーバイザーと10日的に機能連携できるストレージストレージの機能といったものを利用して選択してセルスタービスポータルの要件事項をクリアにしていくことが非常に重要だと考えられますそれでは最後になりますがまさきさんより今後の取り組みについてお話しいただきたいと思いますそれでは今後の予定について話したいと思います今後の予定としてはマニラを進めていきたいと考えております共有ファイルシステムは社内でも重要がありますしマニラによって手難闘を超えたファイル共有も可能になります他にもヒートによるオートスケールを使用したときに共有ファイルシステムが構築できたりなどさまざまな可能性を秘めていると思っておりますまた共有ファイルシステムは物理環境時代から使われてきたこともありますしありサービスのユーザーからしても導入が用意ですナスを利用するアーキテクチャも今後なくなることはないでしょうし共有ファイルシステムは使えないことによってイヤス環境に移行できなかったユーザーにとっても労法といえると思います最後に本選手とまとめをお話ししたいと思いますまずオープンスタックを利用することで得られるメリットは標準化されたAPIの利用と不利なハードウェアリソースの利用またそれによるデータセンターの中小化であることストレージのコンポーネントでは火曜性 効率性 安全性の高い環境を提供するために実績とノウハウが蓄積されたベンダーのストレージを利用していることオープンスタック環境のリベンスでの向上にはユーザーとベンダーの競争が非常に重要であることをご紹介させていただきました以上でセッションを終わりますもし質問などありましたら後ほど我々まだ少しこちらにおりますので是非直接来ていただければと思いますありがとうございました