So, hi, everyone. Thank you for taking my presentation.英語はここまでで、今から日本語で発表させていただきます。それでは、エンタープライズ適用に向けたネットワークログ採取の課題と取り組みと題しまして、富士通株式会社のフルカーが発表させていただきます。本日はよろしくお願いします。少々お待ちください。まず、自己紹介からさせていただきます。私の名前はフルカー有志郎です。富士通株式会社に所属しておりまして、主な業務としては、プライベートクラウドの運用管理のソフトウェアであるサーバービューリソースオーケストレーター、通称RORの開発に携わってきました。その後、パブリッククラウドである富士通クラウドサービスK5の設計開発に携わってきました。これを経て、現在はオープンスタックコミュニティのニュートロンで、以下の開発に従事しております。1つ目は、本日の発表内容であります、ネットワークパケットのログサイシュAPIの設計開発。2つ目に、富士通のネットワークのベンダーのプラグイン、ML2プラグインのメカニズムドライバーの開発を行っております。3つ目は、ベアメタルサーバーの配備のプロジェクトであるアイロニックというところと、ニュートロンをインテグレーションすることで、マルチテナントを実現しつつ、ベアメタルサーバーを配備するという、ベアメタルサーバーのマルチテナント配備の対応の取り組みを行っておりまして、4つ目に関しては、DVRというのはニュートロンにルーターがあるんですけれども、分散仮想ルーターですね。DVRにおける、さらにSNATの機能も分散させようというところの設計を行っております。本日はこの1番のところの発表になります。アジェンダですが、このように発表していきます。まず、開発のゴールと、私が今回開発に取り組んでいるもののゴールと、それとオープンスタックの現状。そしてこれまでの取り組み、リバティに向けて、どういう取り組みしてきたか、満たかに向けてどういうことをやっていくかということについて、簡単にご紹介した後に、現在まだフィックスはしていないんですけれども、提案中であるネットワークのパケットログのAPIの、パケットログ最初のAPIの簡単な概要と、少し性能を図りましたので、性能について発表できればと思っておりまして、最後に今後の取り組みという順番で発表させていただきます。まず、開発のゴールと現状についてなんですけれども、私の今回開発の目指すべきゴールとしましては、いかの二つであると考えています。一つ目に、何かトラブルが、運用中に何かトラブルが発生したときに、迅速かつ確実に原因究明ができること、これを満たせ必要があると考えております。やはり、オープンスタックをエンタープライズに適用するという目標を掲げているので、万が一トラブルが起きたときでも、何が原因でどういう修正を適用すれば、このゲーラーは解消されるのかということが、正確に迅速に把握してお客様に正確に伝える必要があるので、この一番というのは必ずやるべきことだとしています。二つ目としては、お客様が正しくネットワークのセキュリティの設定ができるということです。これは何を言っているかというと、実際にニュートロンではセキュリティグループやファイヤーボールといったフィルタリングのものですね、何を通す、何を通さないというセキュリティの設定ができるんですけれども、お客様がそれを設定されたときに、このとき正しく通すべきものを通して弾くべきものを弾いているのかという確認がやはり作った後に必要になるので、そこの確認ができる機能としてセキュリティ設定ができるというのは必要な機能だと捉えております。これをオープンスタックのロールとして考えてみると、インフラ管理者としてはやはり一番を満たすためには実際にサーバー側でAPIのログと発行されるんですけれども、そういったログを見て、どういったAPIが投げられて、どういったエラーが起きたのかというのを集めて、決断できるということが必要です。また、手段取り用者、お客様に関しましては、自身で作成したファイアウォール、セキュリティグループのルールというのが正しく設定できているかどうかというのを確認するという機能が必要になります。繰り返しになりますけれども、なぜやっぱりパケットログの最終が必要なのかということで、もう一度説明したいと思いますが、やはりお客様としては、自分で設定したルールというのが正しく設定できたかどうかというのをどうしても確認される必要があるので、例えば下の図でいうと、VMとネットワークとサブネットとルーターというのは基本的なリソースでこのようなネットワークを構成したときに、セキュリティグループというのはVMのポートことに設定して、ファイアウォールというのは仮想ルーター上で動いておりますが、それぞれファイアウォールにはルール設定しまして、セキュリティグループにも同様にルールを設定します。このときに、紫色のパケットは通さない、はきします、ドロップします。そしてオレンジの通信だけは通しますというふうな設定をしたときに、実際に設定はしたけれども、どのルールが評価されて、パケットが通過したのか、はきされたのかというのは、どうしても設定するだけだと確認ができないので、それを確認する必要があるというところで、パケットログの採取機能というのが必要だと言い続けました。なのでやはりゴールとしてましては、インフラ管理者が複数のAPIの、複数のサーバーからAPIの信号ログが映像可能であること、そしてご客様、手間取り用者としては作成したセゲーティーファイヤーボールが正しく設定できていることかを確認できること、こういったサービスを開発する必要があると考えております。しかしそうは言いましても、現状のオープンスタックでこのシステムが満たされているかというと、少しダップがあります。どういったダップかというと、インフラ管理者側が複数のAPIの実行ログというものを診断できることに関しては、いろんなプロジェクトで強化されてきているんですけれども、お客様の立場ですね、手なんとの利用者から実際に設定したファイヤーボールやセキュリティグループのログというのは、取れている機能に失礼しました。お客様からファイヤーボールやセキュリティグループのログを採取する機能があるかどうかということに関しては、まず現状ないですし、そもそもネットワークのパケットのログを出す機能がありません。ですので私はここに集中して、まずネットワークのパケットのログを出す機能を開発するということで、ニュートロンで取り組んでおります。次にリバティから開発を行ってきているんですけれども、リバティでどういったアプローチをしてきたかということについて説明していきます。まずリバティでのアプローチなんですけれども、もともと私が提案していた内容としては、既存のセキュリティグループルールファイヤーブルールに対して、そのルールはログ設定を行うかどうかというフラグのような、フラグを指定させる方法で実現することを提案しました。ブループリントを2つそれぞれ発行して、それぞれに例えばファイヤーボールを作る際、あるいは変更する際にパラメーターの中にロギングというパラメーターを入れて、これのトゥルーフォールス切り替えることでログ設定を行わないというのを設定させるように提案してきました。セキュリティグループも同様に提案したんですけれども、こちらの提案をしたところ、実はセキュリティグループのAPIというのはAWSのセキュリティグループとご完成を持っておりまして、私の提案のように既存のレストAPIに対して、フカラムやデータベースに属性を入れるということで、その時点でAPIの被護感が発生してしまいました。ですので、既存のAPIに変更、拡張するというアプローチに対しては、コミュニティ側からは同様得ることができませんでした。ですので、私の出した提案というのは、リバティでは、オープンスタックのコミュニティでは、ある機能開発をする際に必ずその機能に対して重要度、インポータンスというのは設定されるんですけれども、私の提案に関しては、この時にリバティでは重要度というのは設定されないままです。ですので、この経験を踏まえまして、見たかに向けてどういったアプローチをしたかと言いますと、現在見たかに向けてアプローチを変えまして、やはり既存のAPIに手を加えることがやはりコミュニティでは、コンセントを得られなかったというところですので、既存のAPIを手に加えて新規にパケットログの最初を行うというAPIを提案しました。まだこのロギンでAPIはまだ仮称なんですけれども、こちらは現在ニュートロンのチームとファイアウォーラーザーサービスのチームのコアのレビューアーの方からレビューをしていただいている段階でして、まだ設計段階ではあるんですけれども、見たかに向けてはコミュニティ側で本機能の重要性というのを認めたいただきました。ところでインポードダンスの方をハイに設定させていただこうとができましたので、今後私は設計も少しファイアウォーラーのチームと、ニュートロンのチームと協力して設計を繰り返していて、見たかでこの機能を取り込みたいと考えております。それでは、現在提案中のネットワークのパケットログの最初のAPIについて今から発表していきます。まず、概要なのですが、どういったAPIかと言いますと、ニュートロンのリソース、ファイアウォーラーセキュリティグループというのを対象にしていますが、こういったリソースのパケットログ最初を行うAPIです。このAPIの概要、簡単な概要なんですけど、まず大きくどのリソースのログを採取するのかというのを指定ができます。これをログリソースという新たなリソースをフェイスさせていただいて、例えばファイアウォーラーのルールでしたり、セキュリティグループのルールしたり、あるいは今後、拡張していくとして、例えばロードバランサーでしたり、そういったものを指定する、リソースの種類を指定するものになっております。2つ目に、そのログの設定を指定しました。ログのレベルですね。インフォレベルで撮るのか、デバークで撮るのか、そういったのを指定できるログリソースというリソースを新しく提案しました。これでログのレベルでしたり、どこにログを吐くのかというパスですね。そこの指定をできるようにしています。これだけだとイメージが湧きにくいと思うので、簡単な例を用意したんですけれども、これでももしかしたらわからないかもしれませんが、説明していきます。まずはじめに今、ファイアウォールルールのログリソースを定義します。定義した後に、ファイアウォールルールのログリソースに対して、ログレベルを何に設定するか、そしてログの出力先をどこにするかという指定をさせます。ロギングドライバーを作成するときに、ログレベルでバック、出力先をスラバーのログに吐く、出力するという設定を行います。これが出来上がった後に、ログリソースに対して、ログの設定を行いたいファイアウォールルール、あるいは今回の場合はログリソースにファイアウォールルールを設定しているので、ファイアウォールルールというのを複数、指定することができます。こうすることで、設定したファイアウォールルールのそれぞれが、ログを取得する対象となって、実際にログの最初が行われるという流れでリソースを作っていきます。また、このリソースというのは、手なんとに独立して作成できるもので、手なんとごとにどういうログレベルで、どんなものを対象にするのかということを指定させることを可能としたAPIになっています。このログリングのAPIなんですけれども、構成について説明します。実際、ファイアウォールとセキュリティグループ、そもそもどういうふうなものを使って実現されているかということについて、簡単に説明させていただきますが、構成としては、ファイアウォールセキュリティグループというのは、セキュリティグループはコンピュートノード上でIPテーブルズが実際動いて設定が行われておりまして、対してファイアウォールに関しては、ネットワークノード上のネームスペースですね。一つ、リナックスのカーネルの機能なんですけれども、ネットワークノームスペースの中でIPテーブルズが動いているというところで、ファイアウォールというのは実現されています。この構成に対して、私の提案としては、一つU6D2というパッケージを使いまして、ネットワークノームスペースの中でプロセスを立ち上げて動かしております。これなんでかというと、今回ログの出力にIPテーブルズのログオプションを使って実際にログを出力するというのを提案しているんですけれども、ファイアウォールの場合は、ネームスペースの中でIPテーブルズが動いているので、この中からホスト上のこのRCソグDに対しまして、ログを設定するときに、カーネルのアップデートに伴って、そこがセキュリティー上の理由で禁止されてしまっているため、一度U6Dを使ってユーザー空間の方から直接RCソグDにログを出力することで、ネームスペースの中から相当に対してログ出力を実現するということにしています。そして2つ目なんですけど、ログの保存先とログファイルの単位についてなんですけど、ログの保存先は2種類ありまして、ローカルホストの保存する方法と、指定者サーバーで転送するという方法があります。ローカルホストの場合でしたら、それぞれコンピュートノードとネットワークノードのローカルホストにファイルをすることができます。また、保存したログなんですけれども、これは手なんとことにファイルを分割しているため、複数の手なんとが1つのログファイルで管理されることがなくて、手なんとことにそれぞれ独立したファイルで管理されています。管理することができます。そして2つ目なんですけれども、指定したサーバーにログを転送するというオプションも選ぶことができます。こちらの機能はRCソグを使って実現しようと考えてまして、実際にセキュリティグループの場合でしたら、コンピュートノード上から指定したサーバーに対してログを転送します。ファイアボールの場合も同様にログを転送します。転送する際に使う経路ですけれども、もちろん管理欄の方からログを転送します。そして実際にログを出力するわけなんですけれども、ログにどういった情報を含めるかというところも、このAPIでは定義をしておりまして、実際にログを何に使うかというと、やはりトラブル調査ですので、トラブル調査としてはまず、どこのテナントに影響があるのか、実際にパケットを見たときにどういった共同をしたのか、例えばそのパケットがTCPをドロップしました、ACTPをアローしましたというふうな、そういった挙動を確認できる情報というのを含める必要があるので、こういったタイムスタンプ、テナント、そしてログレベル、そしてリソースのタイプ、例えばファイアウォールルールでしたり、セキュリティグループルールでしたり、そして対象のIDですね。例えばファイアウォールでしたり、セキュリティグループのそのもののUIDと。そしてイベントとしてはどういう共同をしたのか、アロー、TCPでしたり、ディナイン、ACTPでしたり。そして最後にペーロードとして実際、今回はIPテーブルズのログを使って吐いているので、その情報そのままここに吐くというところでログを出力するようにしています。今回IPテーブルズを使ってログを出力するということなので、ローカルホスト、あるいは転送先のサーバーに出力されたらログが蓄積されます。そうすることで、やはり従来のIPテーブルズを動作させるよりも、それぞれの濃度に対して負荷が変わってしまうことは明らかですので、このIPテーブルズのログを使って出力するというアプローチがどのくらい性能に影響を及ぼすかということを調べるために、ちょっと簡単ではあるんですけども、性能測定の方を行いました。今から性能評価についてご紹介していきます。性能評価に関してですが、まずVMを2つ用意します。1つはパケットをここから投げる、ソースとなるVMを1つ立てまして、目的地がこのWebサーバー用のVMインスタンスです。この通信なんですけど、必ずルーターを経由して通信するというイーストウエストトラフィックを行う。もう1つは外部からですね、外部のテストEXTって書いてあるマシンからルーター経由してWebサーバーに届くというノースタンストラフィック。この2つのトラフィックでスルークットを測定しました。測定環境なんですが、いかのような環境になっております。それぞれのデータラン、エクスターナルラン、ネジメントランは1Gbps、そしてコンピュートノードとネットワークノードのスペックは同じスペックとしています。ネットワークタイプはVLANを使っておりまして、ルーターはレガシーの構成ですね。レガシーのルーターでネットワークノードでのみ、ルーターが稼働しているという構成にしております。またVMゲストに関しては、1コアで2GBのメモリを使うという構成です。次に測定内容についてなんですが、どういう条件で性能評価を行ったかなんですが、今回これが先ほどの物理の構成ですに対しまして、これを論理的に表したものがこちらになります。こちらでファイアウォールとセキュリティグループのルール数というものを2個、100個、500個、それぞれにおけるスループットとCPUの使用率を測定しました。それらの場合においてそれぞれ3つの状態で図っています。1つはルールに対してログサイシュを行わない、つまり現状のままですね、アズイズの構成でどうなるということ。それに対してログサイシュを行ってローカルホストに出力するパターンとリモートホストにログを転送するという2つのパターンを比較しました。ここからこちらに向けて転送する際にこことここのルールを変更して、ここに関しては特に切効、変更を行っておりません。全部通すルールにして、こことここに対してルールを増やした時にスループットとCPU使用率がどうなるかというところを測定しました。こちらがスループットになるんですけれども、左のグラフがイーストウエストトラフィックの結果を表しておりまして、右側のグラフがノースタウストラフィックの結果を表しております。まず左のグラフに注目してください。横軸はファイアウォールのウェアセキュリティグループのルール数を表しておりまして、縦軸はスループット、メガBPSで表しております。そしてグラフのそれぞれ、青色が基準となる元々の構成で最初行った場合、つまりログを取らない構成です。赤色がシスログでローカルにログを保存した場合の構成です。赤色が、緑色がRシスログを使ってログを転送した時にどういったスループットが出たかという結果になっています。このグラフを見ると、ログを取ってもログを取らなくても性能にほぼ低下はありませんでした。厳密に言うと少し落ちているんですけど、平均で1メガBPSログを取った時に比べて1メガBPS落ちているということが分かりました。続きまして、その場合のネットワークノード上でのCPUの使用率を計測しました。まず、イーストウェストトラフィックの場合ですけれども、ログを出力を行わなかった場合に対して、起こった場合だと使用率が3%から4%上昇しておりまして、こちらはこの傾向はイーストウェストトラフィックだけではなくノースタートラフィックでも同じ傾向が出ております。続いて、コンピュートノード上のCPU使用率の結果になりますが、こちらはネットワークノードに加えて使用率が高くなっているんですけれども、これはコンピュートノード上で動かしているので、そのVMの分のCPUの使用率が加算されているため、増えています。ただ、やはり青の時期、基準となるログを取らなかった場合に対して、ログを取った場合だと、CPU使用率は3%から4%上昇しているという結果になりました。今、測定結果のまとめになるんですけれども、スループットに関してはログを取陸しなかった場合とした場合に、比較した場合、平均1mmbpsの差というところで、ほとんど性能に変化はありませんでした。また、CPU使用率に関しては、例えば1000ルールの場合だと4%程度の上昇というところで、スループット及びCPU使用率に関しては、現在提案中のIPテーブルのログを使うということに関しては、供用範囲内かなと判断しました。最後に、今後の取り組みについて説明していきます。今後の取り組みについてなんですけれども、まず、満たかに向けては、今私の方で提案させていただいているネットワークパケットのログ採指機能の開発、これを満たかで実現してしたいと考えております。満たかでの実現ができた以降でしたら、今回満たかでは対象をセキュリティグループ、この2つのログ取得の対象としておりますが、今後この2つだけではなくて、例えばロードバランサーでしたり、他のニュートロンのリソースに対してもログ取得ができるということを目指すために、対応リソースの強化を目標にします。そして3つ目なんですけれども、これが冒頭でも少し説明させていただいたんですが、やはりお客様自身がこの入ったログを実際に取得して確認できるサービスの開発というのが最終ゴールとなっていますので、こちら、こっちですね、こっちの方の開発というのをやって自分たち出力したログというのを利用した確認できるそういったサービスを作っていきたいと考えております。以上で発表を終わります。ご清聴ありがとうございました。