意気を寄せていただきまして、よろしくお願いします。今日は、今ご紹介と分かりましたとおり、第一、保障用リナックスの適用拡大に向けたとおり、コミュニティの適用拡大恐竜の必要性について説明します。今日の発表内容なんですけれども、軽くご紹介させていただきまして、その後、最後の拡大に至るまで順番にお話しします。まず、ご紹介なんですけれども、私は現在、エンギー統一センターというところでオープンソースの管理上に注視しています。私の担当は、一応OS担当ということになってまして、オープンリナックスですね、区間センサー公職業などを行っています。一方、アップストリームのコミュニティ、当然リナックスを中心としてコミュニティですけれども、スポールでの開発活動ですとか、恐竜の発表ですとか、せっかくとも行っています。下は、エンギー統一センターの立ち位置ですね、NTTグループ内容の受け取り立ち位置とコミュニティですとか、外部との連携の関係を示しています。簡単に説明しますと、NTTグループ各社に対して、OSをサポートするというのが、よく発中心になってまして、他にも、オープンソースをこちらから適用推進ということで使ってもらえるように推進活動を取り組んだりですとか、右側の方は、外部のコミュニティと連携した開発を行っていることですね。私の立ち位置はこの真ん中のところで、左側のサポートもやっていますし、私の右側のアップストリームのコミュニティとの関係をやっています。このような発表は、こういう両側を見て真ん中に立ち場として感じた問題点についてです。最初にちょっと順序として、最近、リナックスサーバーの利用形態と活用の目的を大座派に分類して、ちょっとお話しさせていただきます。一応、便利状を3つ分けています。一番上から、アイエンドの性能資格は高いユーザーで、その下に一般的なということは適切ことかわからないですけど、多くの企業で使っておられるユーザー。一番下、個人レベルのユーザーです。このようなハイエンドの性能資格は高いユーザーなんですけれども、典型的な例としては、今日はツイッターの紹介なんかも連中にありましたけれども、世界規模のインターネットサービスを展開しているようなところですね。こういったところでは、バクライナー数のサーバルを抱えていたりですとか、あと、一台あたりから小さなスーパーセントの性能工場であっても、サービスをスケールさせることで、かけたコストを回収できますので、巨額の開発肢みたいなものをどんどん次ボムっていうのもそういう読書もあります。サービスもとにかくスケールさせて回収できるという読書があります。最近ちょっと、委訳に関するニュースサイトなんかで呼び上げられていたんですけれども、こういった企業、特に欧米の企業が多いですけれども、大量のカーネル開発者をカッコイコンで内部にOSSのエッジにカッコイコンでサービスを開発するそういうスタイルにとっている結構があります。まとめますと、サービス規模の追求がメインであって、そのためにかけてコストも大きいです。もちろんコミュニティー発表みたいな場合での発表とかそうですけれども、開発コミュニティーに中国もやっぱり受けやすいです。サイセンターの新しいことに取り組むということが多いですので、中国も受けやすいという特定があり、真ん中にいつくる一般的なユーザーに関してなんですけれども、こちらは例えばサービス範囲が限定的であったり、まいりと言っているわけではないですけれども、無限にサービス範囲を広げたいという用途ではない限定的であったり、あとは、とにかくシステム構築費用はできれば押さえたい。当然ですけれども、あるいは限定に押さえたい。あるいは限定の制御要件を出せればそれでいいんだって割り切って考え方だったりします。当年、そうするとかけられるコストページにあっているのも限定的な数みになっています。まとめますと、決末性の要件を出しつつベンダロッピー回転ですとか、消費用削減みたいなオークンソースのもとパラリーの敵ですね、使用目的を達成したいということです。おそらく日本でも非常にこういったユーザー一般的だと思うんですけれども、残りながら一番上のハイエンドのユーザーの活動に比べて問題があると思うんです。個人レベルのユーザーなんですけれども例えば、作るとも開発用ですとか個人でデスク得環境でオーススイス使っているというようなユーザーが考えています。用途は多様ですね、趣味かもしれませんし個人的なプロジェクトかもしれません。特徴としては企業ユーザーと大人性悪がないバグの報告ですとか自分が思いついたような機能ですね、開発結果というのを自由に貢献しやすいというのが特徴あると思います。個人レベルのユーザーで一番下に変えてしまうとなんとなくその存在感としてなるように思えてしまうかもしれないんですけれどもオーススイスのコミュニティ特徴的なところがありましてこういった個人レベルのユーザーが実はフォアな開発者だったりというコミュニティもたくさんあります。ユーザーも無視できない存在ですね。こういったユーザーが開発しているものが従管したハイユーザーの心に使われるような気もなったりすることもありますので非常に重要な存在。今ちょっと最後に申し上げましたけれどもこういうキラミッドのような形で例えば新しいハードウェア、何か最新のハードウェアが出たりとかメモリーとかCPUみたいなものが大容量になったり風が大切に最初にハードウェアに触るのは一般的にはお金かけられるハイユーザーでやっぱり企業ユーザーでやったりすると思うんですけれどもまた大体時代が動いていくことに上で使われたいようなスペースのものが下に流れていくのが結構ありますので理想としてはこういった新しいハードウェアを活用するユーザーのっていうのが下に広がっていく必要があると思います。ただ、難しいのは進むのが広いユーザー下の方のユーザーになってくるほどいろいろたくさん増加するノウハウェアです。個人全て対応したり修復したりノウハウェアを蓄積させたりということが困難になってくる。この後、ちょっと私が今言ったようなノウハウェアをないで全部持ったりするのが困難になるという話につなげるために準備として最近の修復なくサーバーの提供というのをお話しさせていただきます。僕一部だけ紹介していますけれども例えばサーバーの方ではさっきちょっと話しましたとおりコアスコレックスを活かしますしメモリも大王になってきます。そのためのアキテクチャとしてユーザーみたいなマシンみたいなものがなってきたりしますね。ネットワークの方でケンジーですとかそれに対応したような関連は当然そういったサーバー変化に対して対応する必要がありますのでまず動かせるリソースに対応した関連のコープが入ったりですとかあとはできるだけヌーマみたいな構造新しいものが入ったとしても既に動いているアプリケーション2がそういったものがあまり意識させずにうまくいいところだけ取りたいというかそういう特徴がある開発があります。それとだけ数字のレイアンをあげますと普通のマニメ企業で使うようなサーバーでもマニメのマシンで最低数十ファレストとか数十ギアバイトなんてあったり前で100ギバークバイトを100ギアバイトを起こすようなメモいっぱいも時々見られます。ゴールはこういったりなくサーバー上のアプリに搭載されたりソースをちゃんと活用させてシステムの性能要件を満たしたりここで言ってる性能要件というのは先ほど書いたピラミッドの一番上の性能思考が高いユーザーが目指すような何パーセントで小さいのでもいいので最低下を目指しますというよりは大体にソースを使って決められた性能要件サーバーからためにかけたコストを見合うくらい程々の性能要件という私たちが経験したクラブの記念について紹介します。最近のサーバーに対する対応するための機能も開発されているしどうも宣伝されていることをそのまま受け取りをこれだけつけにしますというのがいつも出てきますので恐らくその上のサーバーの上にミナックスをインストールして最近のアプリケーションなんですけれどもここではコストブレースという例としてサーバーの上にミナックスをインストールしてコストブレースという例として出しますけれどもこういったもののインストール性がうまくいくんだろうというのが一般的な感覚ですただ現場ではいろいろ苦しんでいる現状がありませんので実際この構成でどういうトラブルが発生してどういうふうに対処することになったかというのをご紹介しますTHPというカーネルの機能ともDPの相性の問題はメモリが64GBというようなメモリだったんですけれども普通はこれくらいのメモリのサイズになってくると通常の4キロ倍程のページの管理だとページ数が非常に多くなって管理オーバーヘッドが大きくなってメモリのリソースを理想的な活用管理オーバーヘッドを最低十分に理想的に使うには少しページ数が大きすぎるというようなサイズになっていますこういったものに対応するためパンパシからフィルシページというものを勘配られていまして実際になっていても使えますこれはですねギメガバイトですとかそういったある程度大きい3位のページを使ってメモリを管理する機能ですでカーネルはTHPTはトランスペアリントの略なんてですけれどもそういったフィルシページを使わせない形で使わせるための機能を持っていますで私たちが用いたレールロックでもこのTHPがデフォルトいうふうになってまして基本的にはそのまま使いたくなるユーザーカスルを使いたくなる状況でした何が残ったかと申しますと初期のレールロックではTHPそのものが不安定でしたこれいろいろなバグの情報レーションパートのご存知の方もいると思いますそもそもKGP機能不安定だった時期がしばらくありましたしあとはTHPサーバーみたいなサーバーに対してカーネルが自動的にKGPページを割り当てたりそのためのメモリのデフラグ的なものを動かすというのが相性がいいのかという問題もありました私はこの場合にKGPをぶっ壊してそれに専用権満たしたので安定動作するようになったのでそれで良しとしました国格度は単純なんですけれども現場のユーザーからするとTHPはさっきお話ししたようなメモリの管理をわへと下げていろいろ性能向上につながる機能です宣伝されているものですのでということに対する真理的に傾向があるわけですねなので動かしても何も問題ないでしょうかというに対して壊り切って停留させての動きを見たせばいいんじゃないでしょうかという提案をして動かしてもらいます同体をしたかも話すし今、特徴なんですけれどもメモリがノードという単位分かれていますねメモリとシーティングペアが一つのシンピュージョンのコアからすべてのメモリに対してきっとのスピードが速さでアプセスできるわけではないという対象でない構成が特徴ですこういった構成ではタスクが結果としてどこに配置されるかというのが実は専門に少し提供しますこういったサーバー上でホストグレスを動かしたとき何が起きたかという話なんですけれども特に何もしないで普通に使おうとしていたユーザーが片方のノードに収まらないメモリをホストグレスしようとした場合にメモリの使用逆に硬い折が生じていろんなレイヤーいろんなレベルで問題が起きて動作不安定になったこういう問題が起きましたもちろんヌーマ上でうまく最適化するようにタスクを配置させることができればそれだけ極所性からの性能の目標を受けられるのですけれどももう生きて割り切ってしまってメモリきっと使用するようにメモリだりるみたいなことをしてしまって土産で活かさせるというのが一つの割り切った考えが私と左右したもの実際は最近カーネルの方ではこういったヌーマジオのバランシングの自動的にするような機能を開発されてはいるんですけれども現状レラナルにレラナルには入りましたけれどもまだ未成績って言わざるを得ない状態ですしやはり割り切って安定動作するように対処するというのが現場ではところどこに必要になってきます今はちょっとカーネルとヌーマに関するような問題をちょっとご紹介しましたけれどもプロジェクト試験で見ると実は問題はそういう小数のものちょっと対応すればいいという話ではなくてカーネルに関するアプリケースの講演の中にもたくさんしなければならないですしカーネルにはそのままいろんな新規のどんどん入ってきまして設定もどんどん増えますサーバーもどんどん複雑になってきますのでサーバーご用の設定もあるかもしれないですそれぞれに対してそれぞれのコミュニティーですとかコジェクトユーザーのグロープかもしれないですけれどもとにかくノーファーが存在していてものによってはそのノーファーの信頼性も基本だったりします最近の傾向として確かにこういったものに対してクラウドがすべて解決するんじゃないかというのもあってやっぱり多くのシステムが現実にすべて今クラウドにこうできるわけではないですしかつクラウドで対応できないようなスペックのシステムというのもありますのでクラウドが万能の処方箋ではないですなのでクラウドの場ですべて解決という極端な論句調が最近をクップレートとしてこういった場での話をちょっと応援してしまうと一部を呼べきのユーザーここに振動化が処置して問題が起きるんじゃないかなと思っていますこういうユーザーのためにはやっぱりプロジェクトごとに多数のノウハを全部エンジニアカッコイン本で保持しなくてもいいようにコミュニティみたいな場所で共有されているノウハが欲しいと感じています今ちょっとノウハの共有に触れましたけれども現代ではノウハ共有でどういう状態にあるのかを少しお話します2つ目が感じるレベルテリックスか課題があります1つ目がノウハの3歳2つ目がチースカーですとか最新情報の不足ですねあとはいろいろノウハがあるんですけれどもノウハ感が安心の問題みたいなものがあります1個ちょっとご説明しノウハの3歳なんですけれどもおそらく OSSで何かシステム構築することに携わっている方なら改善しておかわるんじゃないかと思うんですけれども何か問題が生じたという時にGoogleで検索するですとかいろいろ何か検索してメイリングリスト個人プローブなどにもしかしたら解決するかもしれないというような情報が押していることがよくありますそれでじゃあ全部解決できるかという話なんですけれどもそもそもいろんな問題があっていろんな選定しなきゃいけない状態で情報を全部収集してくることそのものも困難あとですね現場では全ての機能に対して自信のある専門的なエンチニアがいる場合はこういうことないかもしれないですけれども全ての専門が座っていない現場ではその情報が信頼できる情報かどうか判断するとか非常に難しいそういった意味ではできれば開発コミュニティのオフィシャルなサイトなど信頼できる場所の重要な農学が集約されているそういう必要があること農学のチーム、使うと最初情報の不足なんですけれどもこれはですね例えばさっきサーバーの例としてヌーマンマシーンを紹介しましたけれどもこういったスペースにスペックにそもそも対応していないものがたくさんありますスペースの農学も一部そうだったんですけれども例えばこれチーム年内のサーバースペックではないかなと思われるようなものですとかこれはもうデスク特にしか通用しないんじゃないかなっていうようなチームにいる農学っていろんなところに残っていますこれ個人デッグル農学とかではなくてオフィシャルなサイトの右とかに持ってるような農学でもこういった農学アプリケーションのたくさんありますでですねこういうものが入っていること一つの理由の一つとしてオエセスの開発者って実はサーバー用で使われるような技能を開発している人でも開発マシーンにデスクとしか使っていない人ってたくさんいます特に海外とかですと在託キムで個人のマシーンを使ってコードを書いてデスクしている人たくさんいますのでそういった場合本来は商用用メンタプライブでサーバー使われているユーザーからフィードバックがないと正しい方法に技能制復していかないはずなんですけれども残念だからそういったユーザーからのフィードバックというのはどこのコミュニティでも補足しているとかそういう意味では商用のユーザーからのフィードバックに基づいて補足されたりとか開発の順番につながるような仕組みというのは何かの形で強化されないといけないので今ちょっとコストクレスのノウハウガーというのを話しましたけれどもアポニル開発が古いカーネルを前提としているそのために起こるような問題もドキドキありますこういった場合ですねカーネルロード進化してくるんですけれども新しいカーネルの機能を使いこなせないですとかこれもあったりにしますここのカーネル入りは一気に見ていかないといけない問題でして実際こういった問題意識して回転に向けた動きも一番ありました例えば2014年のイナックスストレージファイルシステマのメモリマネージメントのサービットではコストクレスの開発者が招待されて発動してカーネルコミュニティの技術者と議論したりしていましたとめますと新しいカーネル機能に対する適切な設定ですとかついともはタイムにアプリケーションに提供されるよう連携両コミュニティの連携は強めている必要があります次に濃化感の相性の問題ですこれはですね組み合わせても両立しないことが多いような濃化複数の問題先ほどの問題は機能を増えていて設定すべきものも増えているという話をしましたけれどもそうすると当然濃化の部分に増えていくわけですところが色んな濃化を見ていますと各機能についてその機能単体だけを考えて何かを最適化するための方向みたいなのが単々と色んなところに別々利用に使われていてかつカーネルの機能なんかもそうですけれども特定のユーザーが特定のユーザーのために導入した機能が結構ありますのでそういったものにしか効かないノウハウとかもたくさんあるまとめますと絶対最適化ができていないとなります現場ではどういうものが欲しいかと言いますと特にポスクレみたいな色んなところで使われるような代表的なコリケーションに関してはそれのサーバ上で大きなクラブをなく動かすための実用的でかつあまり項目が多すぎない単純なノウハウというかセットでも集まっていれば非常にありがたいなというそういう気がしています今4つですね私が感じたレベルで課題を紹介しましたけれども当然こういった課題を体験していくためになんかアクションを取るないと思ってましてアクションを取る次第は誰かという考えのところやっぱりコミュニティとかあとキューザーが両方なんではないかなという感じコミュニティとしてのアクションなんですけれどもまずですねノウハウ共有という形の冒険を評価する必要があると感じています例えばハイリングのユーザーが何かすごい目立つ機能素晴らしい魅力的な機能を開発しましたコードをコントリープしましたというタイプのものはやはり冒険として認知したレヤーズって非常に目立つんですねそこに当然お金も集まりかもしれませんしそういったところというのはエコシステムの中で冒険でもある程度うまくいいところだと思うんですただノウハウ共有みたいなものって冒険として評価されないのでそれに対してアクションを構想というモチベーションを受けている仕立ちだとあとはですねノウハウ共有の場所を提供するという基準があるこれはオフィシャルなされているみたいな信頼に出る場所にノウハウがあるとその機能ですとかの範囲について自信がないユーザーでもある程度自信を持って信用して使えるという話そういうのがカーネルに限らず各オフィシャルなアプリケーションでしっかりとされることが重要だと思いますあと古いノウハウの現行化メンテナンスですこれもですねコードに関しては古くなったコードを最近のサーバーですとか最近の市場に合わせて更新するというのは比較的ノウハウに比べればお金も集まりやすく人も集まりやすく今も行きやすいんですけども古くなったノウハウを誰かが喜んで自動で更新してくれるかというと残念ながらそういう現状はないですのでこれをですね現行化したりメンテナンスするようなうまい仕組みコミュニティーで考えなきゃいけないなと思っていますとみますとこの貢献と違って評価される不意ノウハウ協力を流すための仕組みをで所要サーバーからの所要サーバーのユーザーからのフィールバックを集めていきたい感じます対してユーザーとしてのアクションなんですけれども特に企業ユーザーの場合はですね公開できるノウハウを積極的に共有していく姿勢が重要だと思っていますこれはオープンソースのコードの共有と同じような免疫がやはりあると思ってまして公開して共有することのメリットを長かな形で後で自分共有することになると思いますのでこういった姿勢で大事だと思いますあとはですね今日もこういう場もそうなんですけれどもコミュニティーを積極的に活用もっと活用する必要があると思います特に日本の場合ですねこういった途中にいい機会がありますのでもっといろんなアクションを取っていきたいと思ってまとめますと普通的と内部に活用積極的ノウハウをコミュニティーで共有することにメイン取り返してこのコミュニティーで共有することにメイン取り返してオープンソースのエコシステムに各ユーザーがどんどん加わっていきたい以上で今日の話は終わりなんですけれども内容としては最初にイラクサーバーの現状ファーククリングとして搭載されるハイエンとかハードウェアがハイエンでなくてもこの高機能なんでライオンが進んでいるという現状を紹介しまして次に私たちが経験したクラブ事例の紹介としてそういうハードウェアを使って収容システム構築しようとしたんですからどういうクラブがあったのかでかつそのクラブの経験通してどういうノウハウが必要かどういうノウハウ協力が必要か意識したかという話をします最後にそのノウハウ協力の課題についてご紹介してコミュニティというか私もこの両方に読むスタッチはですけれどもここでどういうアウトションを取っていきたいかというのをお話しさせてありがとうございました