マイニアルズ・タクエイト、 キノススピーカー、アシア・ハシーパンこれだけで、あとは日本語でやります昨日のキノット聞いていただいた方ってどれぐらいだしありがとうございます今日はとてもリアクスして話すことができますジェン・ワンと申します参加できて非常に嬉しいです今日のアジェンダーになりますこの4つですまずヤハジャパンの振り返りをします2年前までプロプロエーターのアイアスを作っていました結構頑張っていましたがオープンスタックの仕草に似ているものを作っていました昨日もこれは話しましたもうOSSのエコの中でないと会社が置いていかれますOSSと同じようなインターフェスを持たないと厳しいですこれの問題は運用がていっぱいですね開発とかをやっている時間がなくなってしまいます新しいハードウェアの検証ができなくて古いものを使い続けるというそういう悪循環が起こりましたそして2013年からオープンスタックの評価を開始しました3ヶ月ほどでオープンスタックをリリースしていますこのスピード感やっぱりオープンスタックならではだと思っています初期のリリースでは400台のベアメタルを使ってオープンスタックを構築しました中小化されましたので物理的にどんないったものを選んでもユーザーの体験は変わることはありません新しく納得したアプライアンスを良いタイミングで導入することができるようになりました最初のリリースはオープンスタックへハードウェアのロードバランサーを組み込んだりコークリエーションというのを大事にしていましたニンブルストレッジとは2013年の終わり頃からこの辺の話をしていますこういったことをOSSのエコを活用することが可能になりました今のオープンスタックの環境というのは2つのストレージのアプライアンスと1種類のソフトウェアベースのストレージシステムを導入しています3種類のストレージをこういったことで導入していますが利用者が何を導入しているかというのを意識はしていないです運用者は大変ですねというところがありますこれが現在のオープンスタックの話をします昨日と似たような数字を並べていますプレスカンファレンスの方で溢れたのですが6人の開発者と4人の運用者の割合点になっています特定のその人が特定のプロジェクトを担当するということはありません全てのスペシャリストが全てのプロジェクトに接続していてバグの解析やパフォーマンスチューニングなどを行っていますこれは昨日説明したその20以上あるオープンスタッククラスターを統合管理するためのWebUIになりますこれは昨日説明したその20以上あるオープンスタッククラスターを統合管理するためのWebUIになりますこのそのセントライスされたUIからですねオープンスタックとKVMオープンスタックとVMや全てをコントローすることが可能ですこのオープンスタックが提供するAPIってのは全部同じです弊社には2000人以上のアプリケーションの開発者がいますこれら2000人のエンジニアに対してオープンスタック環境のトラブル解決のサポートチームを僕は抱えていますそしてPublic Cloudとの価格比較になっていますかなりアグレッシブな数字なんですけれどもPublic Cloudは別に高くなることはありませんオープンスタックを使うにあたってはAPIというものを変更してはいけませんAPIが変更されたベンダンドライバーってのはやっぱりあるんですがそれはあまり使うことは推奨しません実際のインフラを支えている僕らみたいなエンジニアとJayみたいな開発者は行動に対する考え方がやっぱり違いますなので我々は必ずコードレビューというのをしています多くのベンダンドライバーが公開されているのですが必ずそのコードレビューというのをした方がいいと思いますさらに独自のデータベースの構造を持つドライバーもありますのでそういったこともなるべく持たせないようにすることが大事ですそして今回ベンダーとコラボレーションした内容になりますコスト意識を持って特異な部分をお互い担当し合ってコミュニティを広げていきますそして今回コラボレーションした内容です問題は今回あった問題というのはインスタンスをクローンした際に時間が非常にかかるといった問題がありましたこの問題解決というのを2年前に着手しています当時はシンダーでボリュームを作る際には毎回グランスからイメージの転送というのがありましたこれでインスタンスをクローンするために非常に時間がかかりますグランスからシンダーに転送したイメージというのをそのすぐにインスタンスに当たっているのではなくて一回スナップショットを取ってからクローンしてボリュームを作るということにしましたこういったことでアプライアンスに負荷をオフロードすることが可能になりますオープンスタックの表面上の動きを変更するんじゃなくて裏側の動きだけというのを変えましたこれは補足情報ですアビラビリティゾーンごとにストレージというのを分けていますこの図にも出ていますが我々はネットアップとニンブルストレージを使っていますこのダイアグラムにはネットアップとニンブルストレージを使いますストレージは重要なデータを貯めますしストレージにはどうしても集中した負荷がかかりますできるだけシンプルな構成になるように努力をしますそしてシンダーをサポートするベンダーストレージのベンダーというのがたくさんありますがしっかりコードレビューとのした方がいいと思いますそしてその他の使い方をしていますオープンスタック上で5万以上のインスタンスそれぞれが20個のパラメーターというのをメトリックスを貯めているデータベースとしてニンブルを使っていますそしてこのメトリックスというのは2000人以上のユーザーすべてが利用できますアイオンのパフォーマンスが必要になりますがニンブルはこれを満たしてくれますそしてオープンスタックを使ってインフラの抽象化というのが成功しましたこういったことでベンダーとかオープンスタックコンティーとのコークリエーションというのが重要だと思っていますオープンスタックにおいて抽象化されるのでストレージのプロトコールはあまり重要ではありませんそしてオープンスタックのストレージというのはホットデータの方やりというのがありますそれではJと答えしますニンブルでストレージストレージのエンジニアをやっておりましてオープンスタックのインテグレーションを主に担当しておりますJ1と申します今回ですねスポンサーの一者ということで今回のサミットの私どもニンブルもブースを準備しておりますのでぜひお立ち寄りいただいてグリーンバッグを持って帰っていただきたいと思いますしまたブースの方には専門家もおぜおりますので追加的に情報が必要な場合あるいはご質問がある場合には喜んで答えさせていただきますまずはイトさんのポイントについてコンビニのデータをご覧いただいてくださいこのように見えますか最初にイトさんがおしゃったホットデータについて私も振り返して申し上げたいと思うのですがこのアプリケーションのワーキングセットというのは通常の場合ですね10%未満であります平均では5から6%となっていますこのワーキングセットというのは普通の場合ですね10%未満であります平均では5から6%となっていますもっと efficient way of using SSD is to only cache working set in a flashthere are other types of datamaybe you don't need to cache in a SSDfor example ray paritysnapshotor downstream replicasand alsoit's more efficient to provide you a wayto ping a volumeentire volume in cache if need toということでフラッシュをより有効的に使っていくためにどうしたらいいかということですけれどもこれはワーキングセットをSSDにcacheするということですつまりray paritysnapshotあるいは仮流のreplicaではないということなんですけれどもこのような形で使っていくということとそれから必要があればボリューム全体をトータルでcacheに対してpining固定してしまうということもできると思いますもう一つ最適化をする方法としてはライトのレイアウトを考えていくということですこれはCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualCasualビルパリの例度をディスク上で 行うことができますそれでは簡単にニーブルのストレージの 歴史とそれからオープンスタックとの関わりについてご説明したいと思います2013年に上昇しましたそして本社がありますのが カリフォルニア35税です授業員は1000名を超え そして世界50カ国以上に6000社以上のお客さまがございますそしてビジョンの完成度と それから実行能力という意味においてディスクアレイの世界では ガールナーによってリーダーと位置づけないとおります 非常に嬉しく思っております2013年からオープンスタックと 関わっているわけですけれども例えばアトランタサミット それからワールドワイドのオープンスタックでなどで経験を 教育させていただきましたそれからシーコンバレー 台湾でもイベントがありましたし本社で市販義ごとに行われている オペレーションミートアップなどの参加もしております スポンサーもしておりますそしてオープンスタックの インテグレーションに対する投資を継続しまたオープンスタックの コラボレーションを通じてお客様が目標を達成するお手伝いを しておりますそしてニンブルがどういった 利点があるかということですけれども非常に効率的でスケラブルな ストーレージのプラットフォームを提供できるということです カスルファイルシステムをベースに使っております また従来のものに比べるとフットプリントが非常に小さい ということで3Uぐらいで収まりますそして非常にこのデプロイメントさらには管理が用意できるということと モニタリング及びサポートランドに関してもできるような システムをきちんと備えておりますそしてパフォーマンスキャパシティなどに 対応するためにスケールアップスケールアウトさまざまな方法が 可能になっておりますそしてパフォーマンスキャパシティなどに 対応するためにスケールアップスケールアウトさまざまな方法が 可能になっておりますこれに収まることができますそして仕ンダーでお使いいただきますとこちらは非常に高パフォーマンスな インスタンスでお使いすることがグランスを使えたことができますし効率的なスナップショットゼロコピークローンというものも対応していますそしてグランスの場合にはフェメラルインスタンスの加速アクセレーションにも使えますしそして非常に効率的なイメージングの管理ができるということがありますそしてシングルリンジョンのオブジェクトスタを作りたいという場合にはすべてを使ってやるという場合にはそのバックエンドとして人物を使えていたことが可能でございますさらにはオープンスタックの使った共通のストレッジプラットフォームという形で構築していたことが可能でございますそしてニンブルのパフォーマンスはデータベースワークロードという意味では非常に高いものでありましてオープンスタックサービスデータベースとしてはすぐでた選択肢であると思いますまたシンターのブロックストレッジとしてもすでに実証済みということですヤフ・ジャパンさんなどを含めましてこのオープンスタックというのを非常に広い用途で使われておりますそれでは次にコークリエーションということでヤフ・ジャパンさんと一緒にどのようなことをやっているのか具体的にクラスターファルシステムを使った共有のストレッジオープンスタックの環境ということでご説明していきたいと思いますさてこのクラスターにもいろいろ方法がありましてイサネットを使ったりシェイドデスクを使ったりしますけれども今回はクラスターファルシステムに手元を置いてお話をしていきますさて3が使われるわけなんですけれどもこちらの右の図にありますように例えばボリュームが5つあって1つがメタデータのこれに4つが出たようということになるわけですがこれらすべてが同じクラスターの程共有するということになりますつまり同じボリュームに対して同時に見に行くことができるわけですということでこのような移列化を行っているということから共通のアクセスができるそしてワークロードの分散ができるということになりますそしてリモートデータは高物価になるかのようにアクセスできるアクセスのトランスパイレンシーも確保できますそしてクラスターの度間で例えばディスクの故障ですとかあるいは通信のダウンなどがあった場合にも対応できるようなポルトトランスなデザインになっていますそしてスケラベリティーマネジメントも非常に優れておりまして簡単にできますつまり新しいディスクやノードをこのクラスターに追加することが中央のAPIから簡単にできるわけですそしてこのクラスターファイルシステムは通常コンピュートとストレージを切り分け別々にしますということでアベレベリティーですとかそれから信頼性の管理に関してはストレージ側でやるということになるわけですここはクラスターファイルシステムの具体的な例としてシェアスティックスタイプのクラスターファイルシステムですGPFS、クラスターXFSOCFS2GFS2具体的な例としましてポジックスコンプライントということでGPFS、CXSFSOCFS2そしてGFS2ののがあります少し深くどうやって仕上がるのかこのクラスターファイルシステムにデータがどのように分散されるかを詳しく見ていきたいと思います例えばこのような例えばイメージがあったとしまして3のシステムにおいてブロックサイズに基づいてまたN数に基づいて分散していきますということはファイルシステムのブロックサイズを決めるということが重要になってくるわけです通常はこのブロックサイズというのはシステムのパラメーターでありまして一旦決めたら変えることができません変更しようと思ったらファイルシステム全体を新しいボリュームに移行しないといけないシステムが大きい場合には非常に大変な作業ですそしてブロックサイズの決め方ですけどもこれはワークロードの種類によりますつまりワークロードがセイクエンシャルであったりですとか非常に大きなファイルがたくさんあるというのはブロックサイズは大きめに設定をする1メガぐらいにしておきますそして逆に小さいものが多いというのはデフォルトのサイズのままにしておいても大丈夫なわけですそしてこのように様々なブロックサイズに対応するためにはフレクシルなストレッジシステムが必要ですそしてこのセクターサイズというものも重要でありまして最も小さなユニットのアイオーをちゃんとファイルシステムはボルムに渡してやることができるかどうかということが大事ですので小さいタイミングということで言いますと4Kかけるいくつという計算になると思うんですがこういったものをきちんと受け渡してできるかどうかを確認しておく必要がありますもちろんこのサイズに関してはストレッジシステムの特徴を見極めてから決めていく必要がありますなぜかと言いますと1バイトミマンあるいは1ブロックミマンでライトをかけようとしますとこのモデリファイライトということでペナリティが発生しますですのでそれを避けるためにはきちんと細かいタイミング対応できるように設定しておくべきですそれではこのシェードディスクファイルのコンフィグレーションに関してですけれども見ていきたいと思いますまず1つ目はこれはメタデータのファイルそれからディスクボリュームのスプリットに関してですどういったメリットがあるかということですけれどもこれはキャッシュに対してこのメタデータボリュームをピニングできるあるいはより効率的効率性の高いファイルシステムやストレージが使えるということですそして万が一ですねスペースが足りなくなってしまった場合にメタデータのところですけれども非常に大きな障害がありますのでシンプロフィジュリムをやっていく際にはきちんと100%このメタデータのボリュームのケアをしてやることが大切ですこれはバックエンドのお話ですそしてスカジアンマップですとかそれからライトセームなどサポートされていないものもたくさんありますのでそういった意味ではクラスタファイルシステムとストレージの間にはシンプロフィジュニングは置かない方が良いということですそれからファイルシステムのサイズに基づいてディスクの数や大きさを考えていくわけなんですけれども一日使ったりは1TBから2TBくらいが良いと思いますしたがってトータルで4TB必要な場合にはボリュームを4つ準備するというようなことになるかと思います一つ大切なのはすべてのディスク、すべてのボリュームを同じサイズで揃えるということですストレージに関してはきちんとモニタリングをシーそして予測するようなシステムを設置していくことが重要です特にパフォーマスに対して液を与えそうなオンラインセントのIOがあるという場合にはきちんと最初からモニタリングというシステムを作っておくことが重要ですそれでは次にリナックスを使った場合のストレージスタッグについてそしてパフォーマスを上げるためにどんなチューニングができるかについて考えていきたいと思いますこちらの図にありますように最終的にストレージのバックエンドに到達するまでの道筋という意味ではまずブロックでレイヤーを通りそれからスカジミドレイヤーを通りそれからスカジのローデベルドライバーを通っていきますはいそしてこのパフォーマンスをさらに上げるためにはどうしたらいいかということでここにあるですね4つのパラメーターを維持していくのがいいだろうということになりますリクエストとそれからセクターとリードヘッドですそしてスカジのMIDTレイヤーに関して通常はSDXXのデバイスとして見えると思うんですけれども3つのパラメーターが推奨されていますスケジュアとマックスセクターKBとそれからリードヘッドKBですそれからどういったプロトコールを使ってこのバックエンドと通信をするかにもよりますけれどもアイスカジなどを使っている場合にはアイスカジ用のパラメーターがいろいろありましてこれで出ているのはアイスカジのコンフィギュレーションのところのパラメーターですセッションの数とQデプスそしてCDMマックスですもちろんストレージベンタイによって通称内容が違いますので変更をかける前に必ずベンタイに相談をしてくださいさてこのような素晴らしいクラスタファイルシステムをオープンスタックでどのように使っていくかということですが一つがこのハイパフォーマンスなファイルシェアのインフラですもう一つはオープンスタックにおけるハイパフォーマンスのサービスですそれからもう一つはどっからのコンテナのインフラでも使いますこのような共通のストレージレイヤーとして使えるということです通常コンテナに関してどういった課題があるかと言いますとやはりローカルでコンテナを使っている場合にはファイルもローカルにありますので別のノードに移動させようとすると難しいということがありますクラスタファイルシステムを使えばコンテナはコミットしてそして別のシステムの方で簡単に立ち上げることができるということですもう一つの用途はクラウドストレージですこのクラスタファイルシステムはコンテナのインフラでコンテナに移動させることができますこれは平立プロセスということ同時プロセスということですので例えばストリーミングサービスなどを提供するにあたってユーザーに対してコンカレントでハイパフォーマンスあるいはロードバランシックといったサービスを提供できますということで他にどういった力で我がコントリブーションできるのかということをヤフーさんといろいろご相談しておりまして例えばマニラに関するインテグレーションですとかアイロニックの方でのインフラに関する貢献を検討しています関数の測定も行いました納税やディスクの数を増やしていくとクラスタファリシステムのパフォーマンスがどういうふうに変わっていくかということに関してはこれまでさまざまな事実もありますしそれからいろいろなことを人々が信じていると思いますいろいろな文献もありますし既存のデータもあります例えば納税を増やせば先継にスケーラビリティが上がっていくと説明することが上がっていくということですそして複数のノードから単一のファイルに対して書き込みをするというのは複数のファイルに対してライトをするのと同じくらい高速であるというような考え方もありますそしてノードの数を増やせばファイルの作成のするプットもそれからリモデリファインに関してファイルのペナルティというのもあるというふうに言われています私たちの行ったテストにおきましてはどちらかというとブロックサイズとそれから相応のパターンの影響を見極めようということでハードウェイとしてはホストが2台角16、コア16、ギガそしてテストファイルサイズが32、ギガニンブルのCS440を使ってこれは10ギガビットEのかける2そして2テラバイトをかける12のハードディスクとそれからSSDに関しては4つと言われています2つのファイルシステムですけれどもそれぞれブロックサイズが違いまして片方が128系もう片方が1メガのサイズですそして2つのファイルシステムですけれどもそれぞれブロックサイズが違いまして片方が128系アイオパターンはランダムリルアイドとスリクエンシャルリルアイドですこちらが128系のブロックサイズのシステムなんですが4系16系32系ということで最大1メガまでいろいろなパターンのものをしています1メガバイトのパターンのアクセスのところがこの薄い緑ですのでそこを見てくださいエゴラのようにこの小さいブロックサイズのシステムということで最適化されていないということがわかると思いますスループットがずっと低いですそれに対してブロックサイズを1メガに設定してマグメガバイトに設定してテストするとこうなりますこのテストで使っているのはiPNGPFSで使っていますそして大きなブロックサイズでセクエンシャルリルアイドリルアイドのアイオパターンにスイクエンシャルリルアイドのサイズが高いブロックサイズでセクエンシャルリルアイドを使っていますこれらのように大きなブロックサイズでテストをしてみた場合にちなみにこれGPFSを使っていますけれどもリードアイドをする場合にブロックサイズが大きい方がパフォーマンスがずっと高いということがわかりますランダムリードが約40%ランダムアイドが約30%改善していますそしてセクエンシャルのリードアイドに関しても13.4%とそれから大きい方がパフォーマンスがずっと高いということがわかりますそしてセクエンシャルの13.4%とそれから5.9%それぞれ上昇していますということは実際に使っているファイルのサイズアセットとサイズが大きいという場合にはファイルシステムもそれに合わせて大きいサイズのものを準備した方がパフォーマンスが最大ですこの場合は1MBのブロックサイズのシステムを使いましたそれからノード数に関してもテストをしています非常に大きなアイオンの負荷が変わったときにノードを1つ追加するとどれだけ変わるかということですそして上側は1ノード下側2ノードのデータをそれぞれ示していますけれどもランダムリードでおよそ27.9%の改善が見られましたシーケンシャルリードでは21.1%早くなっていますということはストレージのパックエンドにかふかがかかっている場合にノードを追加するとリードの方は確かに早くなるけれどもライトの方はリードの方は早くなるけれどもライトの方はそれほど早くならないということです時間の関係でここまでしかご紹介できませんけれどもまだまだ情報たくさんございますのでぜひブースの方にお立ち寄りください本日ありがとうございました