大丈夫ですか?はいHello everyone. Welcome to our session.本日このセッションはJapanese Trackということで私の英語は以上とさせていただきますけれども数あるセッションの中から私たちのセッションを選びいただきましてありがとうございます今日はですねOpenStackを利用したゲームサービスの実装というタイトルで説明させていただきますCTCの金子と申しますよろしくお願いします本日のアジェンダー大きく3つに分かれておりますまず最初にですね見たところほとんどの方日本人なんですけれどもあまりCTCをご存じない海外の方のためにちょっとだけ会社紹介させてください2つ目が今回のメインの内容になりますけれどもこのオートノーマスオンラインゲームアプリケーションとありますこのオートノーマス事実型というところが今回大きいポイントになっております内容としてはオンラインゲームシステムをクラウド上でオートスケールをするという話になるんですけれども従来のフカーベースのオートスケールとは違うアプローチの新しいアプローチのオートスケールというものを私たちの方で実装しましたのでこの内容をご紹介したいと思いますで最後にですねオートノーマス事実型のアプリケーションを支える技術としてCTCが中心となって開発しているラックっていうソフトウェアがあるんですけれどもその内容と実際そのゲームとどういうふうに連携しているかという詳しい解説を最後に加えたいと思いますでは簡単に我々CTCの会社紹介をさせていただきます私たちCTCはですねITシステムの設計開発運用と前ライフサイクルによってソリューションを提供することができるIT トータルITソリューションカンパニーでございますで私たちのお客様非常に幅広い分野のお客様がいらっしゃいまして情報通信をはじめとして金融流通製造工業とさまざまな分野のお客様にITソリューションを提供している会社でございますそして近年私たちCTCはオープンスタックにかなり注目をしております一番下のインテグレーションというところはもちろんなんですけれどもその上でさまざまなOSSのソフトを組み合わせてクラウド環境の自動化を推進するですとかそれ以外はアプリケーション開発のレモーテルロップスの推進ですとかそういうことにも取り組んでおりますそして一番上ですね今日ご紹介するラックっていうソフト絵をベースとしてクラウドネイティブのアプリケーションオープンスタックに最適化されたアプリケーションの開発というものに従事をしておりますオープンスタック全般にあたって高い脳波を持った会社だというふうに思ってください会社紹介こんな感じで簡単に詰ませまして本題に入っていきたいと思います今日のキーワード大きく3つございますオンラインゲームからクラウドしてオートスケール大きくこの3つになります今日の話題としてはこのクラウド上でオンラインゲームのシステムをどうオートスケールするかそういった内容になりますそしてこの3つのキーワードそれぞれ具体的なものに当てはめるとこうなるんですけれどもオンラインゲームというところでモノビットエンジンというものを今回使わせていただいております今回株式会社モノビット代表の本女様にもお越しいただいておりますけれども今回このモノビット様との共同プロジェクトということでこのオンラインゲームをオートスケールするシステムというものを開発をしてきまいりましたそして真ん中のクラウドは当然オープンスタックになりますそして一番右側にオートスケールのところでラックと書いてありますけれどもこのラックっていうソフトウェアを見る様子っていうのをご覧いただきたいと思いますでは具体的な内容に入ってまいりますここではちょっとオンラインゲームのトラフィックについて考えてみたいと思いますゲームの内容によると思いますけれどもゲームのトラフィックというのは常に一定のトラフィックが来るというものではないですね例えば朝夕方の通勤時間帯ですとかそれは深夜の時間帯に高いトラフィックが来るというような特徴を持っていますあるいは月1回の大型イベントとかがある時にはそのイベントの時に非常に高いトラフィックが計測されるとそういう特徴を持っていますオンラインゲームというのは各ゲーム会社さんそういったトラフィックに対する対策の一つとしてクラウド上でのオートスケーリングっていうものをすでにやられているところもなるかと思いますで、一つはスケジュール型のオートスケーリングということであらかじめどの時間帯にトラフィックが給奏するかということが予想できるのであればその前にあらかじめサーバーを立ち上げておいてリスポンスが遅くなるのをステグといったような対策が一つで、もう一つはリソースベースというふうに書いてありますけれどもその付加情報をもとにサーバーを増やしたり減らしたりそういうのが一般的かなと思われますで、実際このオートスケーリング実現しようと思うとオープンスタックで一般的にやられる方法としてはセイロメーターとヒートっていう組み合わせが一般的かなと思いますこれちょっと一つ疑問と言いますか果たしてそれで十分ですかという疑問をちょっと投げかけたいんですけれども短い時間でトラフィックが急増した場合っていうのはCPUの例えば利用率っていうのをベースにしていると実際その付加が上がってからサーバーが起動されるわけですよねなのでやっぱり間に合わないケースっていうのが多々あると思うんですよなので非常に短いタイミングで短い期間で急なトラフィック増があった時にちょっと対応できないのではないかとそれから常に予測通りトラフィックがもう良きしないタイミングで高いトラフィックが急に来たという時もスカーベースの音スケールだと間に合わないということがあり得ると思います今お話したのはスケールアウトのケースですけれども今度スケールインについて考えてみましょうスケールインするって言った場合にゲームサーバーゲームのアプリケーションっていうのは基本的にステートフルなアプリケーションですであるユーザーがといった時に基本的にはユーザークライアントとゲームサーバーの間でコネクションが貼られていて常にサーバー側はユーザーの状態というのを守っているとステートフルなアプリケーションというふうなことが言えますそのあった時に例えばCPU付加とかメモリーの利用率っていうところだけを見てスケールインを用意してしまうとするとまだ1人のユーザー残り1人のユーザーがサーバーが削除されてしまうということもなりかねませんなので何らかのスケールインに関しては工夫が必要なのではないかなと思いますこういった問題に対して私たちは新しいアプローチのオートスケールインというものを考えましたそれがアプリケーションの状態に基づいたオートスケールインのメカニズムというものです私たちは今回これを採用したシステムを開発いたしましたここにオートノーマスアプリケーションという表現をしておりますけれども要はアプリケーション自身が自分の状態っていうのは一番よくわかっているわけですねアプリケーション自身が直接オポスタクトの駅を叩いてサーバーを増やす非常に自立的な動きをするわけですねここでヒートだとか精度メーターとかっていうような外部のサービスっていうのはあってこなくてアプリケーションだけで完結するオートスケールインというものを実現しようとしていますここで大きく従来のオートスケールと異なるところはメトリックスのところですね先ほどのケースだとCPU使用率、メモリ使用率といったものがメトリックスになったと思いますけれどもここではオートノーマスのアプリケーションに関してはメトリックスに関してはそれを使えるものがメトリックスになり得ますここではオンラインゲームを想定したメトリックスをちょっと2つほど書いておりますけれども例えばユーザーの数ですとかバトル型のゲームだとアイテルバトルルームの数っていうものをメトリックスとして採用すればいいんじゃないかなとじゃあこの自立型のアプリケーションどんなメリットがあるかというところなんですけどもまず1つ非常にタイムリーなリソースコントロールが可能ですよというのがあります例えばゲームユーザー利用ユーザーの急激な増加を建置してまらかじめサーバーを増やしておくとゲームが始まってからSCPの付かっていうのが上がるんですけどその前にユーザーがもうタイルにログインしてきた段階でまらかじめサーバーを増やしていくそういう早めの対応が可能になるわけですねあるいはアイテルバトルルームの数というふうに書いてありますけれどもアイテルそのバトルルームの数が減ってきたっていうのを建置して相当スケールをするとそういったことが非常にタイムリーなリソースコントロールが可能なというメリットがありますもう1つシンプラデザインデザインが非常にシンプルだということが言えると思いますさっきもちょっと言いましたけれどもアプリの外側のサービスっていうのが必要なくなるわけですよねモニタリングだったりオーケストレーティングだったりオープンスタックでいえばセイドメーターヒートっていうようなコンポーネントが必要なくなってアプリ自身がそれを全部コントロールするとそういうメリットが上げられます一方で当然デメリットもあるわけですよねそのデメリットの代表というか複雑なアプリケーションのプログラムになり得てしまうという問題があります具体的にはVMの数だったりクラウド上のネットワーク構成だったりそういうアプリケーションが気にしなければいけなくなってしまうというデメリットがありますまたAPIを実際に叩くのでその認証情報だとかエンドポイント情報っていうものもアプリケーションの持つ必要が出てきてしまいますこういったデメリットに対して私たちはラックっていうソフトウェアを開発したという流れになりますラックの解説が後半ちょっと詳しくさせていただきますけれどもここでは実際にオンラインゲームがオートスケールする様子っていうのを表現したデモを作ってきましたのでそれをご覧いただきたいと思います題材としてはマルチプレイヤー型のオンラインゲームでございますオートスケールのメトリックスとしては今回アイテルバトルルームの数っていうものを採用しています詳しい話はもうちょっと後でします今回最初ご紹介しましたけれどもモノミットさんのMOエンジンというオンラインゲームを開発するためのゲームエンジンというものがモノミットさんの方で無料で公開されていますこれを今回題材として利用させていただきましたもし皆さんご興味が終わりでしたらこのウェブサイトを訪れていただくなりこの後ご質問補助さんの方にしていただくなりぜひご興味があればでは実際にデモをちょっとお見せしたいなと思いますちょっと画面の説明をさせていただきます左上が今回のバトル型のゲームのタイトル画面になっています左下皆さんご存知オープンスタックホライズンですねのダッシュボードのネットアクトボロジンの画面を出していますこの赤いネットワークのところにゲームサーバーがまたっているというような感じですこのところがインフラのデモってあんまり面白くないですよねVMが上がって下がっているからつまんないので今回ちょっと3Dでオートスケールスというのを表現するデモを作ってみましたそれが一番右の画面なんですけどこの白いダインみたいなのがそれぞれVMだと思ってくださいこれ一個一個がバトルをするためののを表してみますこれから動画をスタートさせるんですけれども実際にプレイヤーがログインしてバトルが始まってというのをこれからちょっとご覧いただきたいと思いますバトルルバトルサーバーVMを表しています今この左上の画面からプレイヤーがチームを選択してログインをしましたするとプレイヤーがちょっとポコッと表れるんですねまた別のところでプレイヤーがログインをすると2人揃ったということでマッチングというものが成立して3つのうちの1つがバトル解除として使用されますそしてここでバトルが開始されるという動きになりますこれちょっと留めますけれども今回はですねアプリケーション側でこのエンプティバトルルームというメトリックスを使ってます今の構成だと常に最低3つの秋のバトルルームを維持しなさいというようなアルゴリズムが組まれていますなので今3つのうち1つが減った段階で自動的にVMが立ち上げられたこれは外側のヒートとか別に使っていなくてアプリケーション自身がAPAをたたいてサーバーを増やしているそういう動きになりますもうちょっと細かく言うと他のAPAは直接たたいているわけではなくてラックっていうソフトウェアが間にまた入ってそのラックがそのAPAを提供しているというものになりますでもうちょっと続けます実際にバトルしている様子ですねで今度また別の2人のユーザーがログインしてきてマッチングが成立しますすると残りの2つのうちどっちかがバトル解除として利用されますこれで開いているバトルの数っていうのは1になりましたで今ちょっと説明してなかったんですけどさっきもやもやってなってたのはVMが起動中ですっていうことを表現していますで今ようやくこのバトルルームの準備が完了したよということでこの白い代がもう1つ増えたということです実際この数字も2に増えていますで今回のアルゴリズムだと常に最低3つのアーキーベアを用意しなさいというふうにしているのでさらに追加のVMが立ち上げられますアプリケーション自分で判断してVMを増やしているとそういう動きを表現していますで今度はバトル終了のケーススケールインの話に入りますけれどもアプリケーション自身っていうのはバトルの状態っていうのは常に把握できているわけですねなのでスケールインに関してすみませんスケールインのときもきちんとバトルが終了したっていうのを判断した上で安全にVMを削除するという動きをしていますでこの削除に関してもアプリケーション自身が削除するという動きをしていますでもう片方のバトルもそろそろ終了するかなはいバトル終了とともにVMが削除されるという動きを見せしました実際ちょっと見づらかったんですけどこのホライズンのところでもきちんとVMが削除されている様子っていうのが見れますあとは相手のバトルルームの数っていうのがこれで3つになりましたで当然アプリケーションは相手のバトルルームの数っていうものを把握しておりますのでこれ以上追加のサーバーは立ち上げないという動きになります非常にというデモを見せたしましたここまでが概要といいますかデモとゲームの内容についてご紹介させていただきましたここからですね自立的な動きを支えているラックっていうソフトウェアと連携の部分について詳しい説明をさせていただきますお願いしますCTCの西田と申しますここからはラック本体の今回と今回のゲーム環境でどのようにラックが活動しているかということについて説明させていただきますラックはこちらなんですが経済産業所から支援を受けて開発を行っているオープンソースプロジェクトですソースコードの方はギター部上で公開しておりますラックというものがどういうものかと言いますと一言で言うとラックとはリナックスのプロセモデルがそれをクラウド環境に適用するためのツールドになってますこれどういうことかと言いますとまずそのプロセスモデルにおいてOS上のプロセスというものはこちらのプロセス自身がフォークを行ってOSリソースを自ら要求するこの意味でしっかり言っているんですけどもその際そのフォークサイザープロセスというのはそれぞれお役本系を持っていてプロセス間通信IPCって言うんですけどまあこういうことを簡単に通信を行うことができますとLockはこの考え方をクラウド環境に 適用することによってクラウド上の一員インスタンスを 一切プロセスと見出しますそしてLockプロセスの中で 稼働するアプリ自身が自らLockのフォークを実行することで 新しいプロセスをそういう意味だと ここで言うと リソースになるんですけどもこれを簡単に要求することができますとさらにフォークされたプロセス感には 医薬関係が同じくできますのでLockの機能を使うと インスタンスを一プロセスと見出すこのプロセス感で IPCと似たような機能を持ってましてLockプロセスつまりインスタンス感で データの交換がラクにできるというような機能を持っておりますなぜLockというものが今回プロセスモデルを 採用しているかと言いますと自立的なクラウドコンピューキにご実現するためです一方 基本的に現在のクラウドは 外部サービスによって管理されているものになるんですけども こういったクラウドは我々ちょっとタリス的と呼んでますとで 一方Lockのほうは サービスではなくてプロセス自身が自立的にリソースを要求するという意味でそういった自立的に管理できるような クラウドコンピューキングを目指して開発されたものです先ほどちょっとサービスによるクラウドコンピューキングはタリス的だという話をさせていただいたんですけどもこちら細くしますと サービスによるクラウドコンピューキングではオーケストレーションやオートスケールイングサービスといった サービスがあるんですけどもこちらが基本的にすべての新しいインスタンスを起動するもしくは削除するという管理をしていますとそれぞれその際にブートされたインスタンスはお役関係やそういった関係性が特に持たずにそれぞれ独立で稼働していますとさらにアプリケースの中の状態を イベントハンドルなのにエージェントを使って送ることでそこで溜められた情報をさらに元に イベントが発行されてさらに新しい必要であれば インスタンスを起動したり削除したりという管理作業を サービスのほうがすべて行っているという意味でこちらは対立的だと考えていますで 一方 ラックによるクラウドコンビューティングになるんですけれどもこちらのラックによって 同じく最初に親プロセスをブートするんですけれどもそこから先はラックから起動した親プロセス自身がフォークによって自ら新しいラックプロセスを フォークによって起動していくということになりますで さらにフォークされたプロセス感に関しましてこちら親子関係 ペアレンドプロセス チャイルドプロセスっていうような関係性がありましてこれらはラックパイプなどの機能を用いて状態のやり取りを簡単に行うことが できるようになりますさらに またこちらラック自身はアプリケーションの中で利用することも できるのでアプリケーションの中で持っている状態等も 利用してアプリケーション内で自由にイベントを作った上でその情報を基にさらに放行するというような放行してリソースを要求するというような 実装ができますこの意味でラックによるクラウドコンビューティングが自立的だというような意味で今回説明させていただきますこうしてラックによるクラウドコンビューティングにはいくつか利点がありますまず1つ目なんですけれども先ほどもちょっと言ったんですけれども便利なプロセス感通信が利用できますとこちら先ほど紹介させていただきましてラックパイプっていう機能があるんですけれどもこちらを使うとIPとかあとは1Eの識別Cっていうものを意識せずに単にように宣言するだけでお役観でデータのやり取りということができるようになります次の利点なんですけれどもフレキシブルなリソースの自動化っていうことなんですけれども例えばラックによるオーケストレーションなんですけれどもこちら最初にフォークでこちらのフォークで新しいVMを建てることによってペアレントプロセスとチャイルプロセスに対して起動順序っていうような制御ができるのでそれによって順番をきちんと保つって意味で一貫性のある構築が可能になりますまたフォークする際に複数のチャイルを建てるということもできるのでこれによって平ですでも両立することができますさらにラックによるオートスケーリングでは起動されたプロセスがあるんですけれどもそのプロセス自身がさらに自分自身が持っている仕事領に応じて新しいプロセスをフォークするというようなこともできるのでそういう意味でこちらで書いてあるんですけれどもマルチテーズオートスケーリング要するにたらんしきのオートスケーリングができるようになりますとさらにこちらの状態の交換が容易にできるのでより細かいイベントをわかりにしつつ細かい状態からフォークというような作業をすることでオートスケーリングだとかオーケストレーションということができるようになります次の利点なんですけれども素早いリソース要求ができるということなんですけれどもこちらイベントの通信先が特に新しいサービスではなくてもプロセスそれ自身になるのでイベントの通信かけは最初でもアプリケーション感だし最大でもプロセス感の通信になるのでその分外部のサービスを使うよりは法則だということですさらにリソースの要求自体も外部のサービスで使うのではなくて自身から要求をするので同じく外部サービスを使うよりは法則にリソースの要求ができると考えています最後に利点なんですけれども少ない要件ということなんですけれども今回特にこれを使う際に外部サービスというのを利用していないために自由にイベントとかも切ることができるという意味で少ない要件があげられるのかなと考えていますこちらの今あげた利点のうちのいくつかなんですけれども今回デモで紹介したモノビットMOエンジンにおけるそのゲーム環境をオーケストレーションする際先ほどデモで見せたようなオートスケーリングをする際にもちょっと見ることができますなのでちょっと以降ではモノビットエンジンによる一般的にまずどのような構成になるのかということを説明した上でラックが今回そうした環境どのようにオーケストレーションをしてさらにサーバーオートスケーリングしていくかということについて一般的な構成を説明した上にどういうふうに作っているかということを説明させていただきますまず今回 MOエンジンのゲーム環境なんですけれども今回のゲーム環境なんですけれども管理サーバー群と言われているものとバトルサーバーという2つの機能大きくわけで2つの機能に分かれていますまず管理サーバー管理サーバーの機能になるんですけれども大戦ゲームのプレイヤーマッチング処理を行った上でIdleバトルサーバーの情報をプレイヤーに返す機能を持っていますこちらの管理サーバーなんですけれどもそれぞれの役割がちょっとありまして種類的に4つあって別々の役割を持っていますと一方バトルサーバーのほうなんですけれどもこちらですねプレイヤーからの大戦のリクエストを受け取ってバトルサーバーがその処理をしてその処理結果をプレイヤーに返すというような役割を持っていますこのバトルサーバーに関してはプレイヤーの数に応じて負荷が増えるのでその分オートスケールをする必要がありますさらにそのバトルサーバーは自身の情報を管理サーバー要するに今ゲームを使用中だとか今自分はゲームを担当して空いてますという情報を近い位置の管理サーバーにパケット情報として送ってパケットに詰め込んで送ってますとこのパケットなんですけれども一機能であるモノビットライトニングネットワークというアプリケーションプロトコリによって実装されてましてこのパケットが管理サーバーのこちらになるんですけどバトルインフォサーバーというところに送信されてますなのでこうしてそのバトルサーバーの情報というのはこのバトルインフォサーバーという呼ばれるサーバーの中にのアプリケーション内で一元管理されてますとこの情報もとに管理サーバーの一つであるマッチングサーバーがプレイヤーに対してアキバトルサーバーを提供するというような仕組みになっていますこの前提でラックにより今回最終的にオートスケーリング機能を含めたゲーム環境をワンコマンドで構築することができるようになるんですけれどもその時ラックがどのように動いてるかと言いますとまず最初にこのような作業をするんですけれども具体的には管理サーバー群をラックの機能を使ってオーケストレーションをしますとあともう一つがバトルサーバー先ほどデモであったと思うんですけどこちらのバトルサーバーをオートスケーリングするエンジンとしてもラックは今回利用されています実際にラックがどのようにゲーム環境を最終的に構築するかということを説明したいんですけれども今回ゲーム環境をオーケストレーションをしたりオートスケーリするんですけれどもその際にちょっと構築の際に注意すべき要件がいくつかあるのでそれを先に説明させていただきますまず管理サーバー群をオーケストレーションをする時の要件なんですけれどもこちらのシンクサーバーというものがあるんですけれどもこちらがその他のマッチングサーバーとかこれらのより先だってまず起動する必要がありますという要件がありますさらにこちらのマッチサーバーバトルインフォメーションサーバーはこのデイビーサーバーが準備完了の状態にならないと起動できないという形になるのがその部分で純女性を持って一貫性もあるよオーケストレーションする必要がありますということです一方バトルサーバーの方をオートスケーリする際の要件なんですけれどもバトルサーバーの状態を知るためには先ほどもちょっと説明させていただきたんですけどバトルインフォメーションサーバーが今ライブで持っているパラメータに対してアクセスする必要がありますこちらがそのイメージなんですけれども今バトルインフォメーションサーバーがバトルサーバーの状態を今管理しているのでこの情報にアクセスをしないと本当にバトルサーバーが開いているのか今削除していいのかという情報がわからないのでここの情報ちょっと使う必要があるということですその状態は主に3つありましてバトル1がアイドル今使用して開いているサーバーですよバトル2がゲームやっているプレイヤーが今バトルをしている途中ですというフラグになっていてバトル3であればユーズともこちらのゲーム終了しましたというフラグになっていますこのような要件に対応してゲーム環境を構築していくんですけどもでは実際にどういうふうに構築しているかということになるんですけどもまずラックのオーケストレーションの方マリジメトサーバーのオーケストレーションについて説明させてくださいどういうふうな実装になっているかといいますとラックの方でまずシンクサーバーのブートを行いますするとシンクサーバープロセス自身が自身の機能を立ち上げる作業を行った上で準備ができた段階で自身が残りのデービー マッチ バトル4というサーバーをそれぞれ平日的にフォークしていきますとそうするとその他の3台が上がるんですけれども並行で活動した機能したプロセスのうちマッチとバトル4サーバーに関しましてはデータベースの準備が完了したという通知を先ほど言ったラックパイプを使って受領するまで一部の作業を中断しますとこうすることによってオートケストレーションに際に機動順序という要件があったんですけれどもそれを満たすことができるようになりますとこうすることで一貫性と平日的を溜めつつオートケストレーションをすることができます次に楽によるオートスケーリングのほうになるんですけれどもこちらのほうはバトルインフォンのアプリケーションの中にそれを判断するためのレータがあるということなのでバトルインフォンサーバーのアプリケーションの中でラッククライアントというツールがあるんですけどそれを用いてアプリケーションとして必要であればフォークを切り落していくというような実装になっています例えばこちらの左の図を見ていただきたいんですけれどもアイドル中のサーバーが少なくとも2台必要ですというような条件になっている場合こちらの左の図では今現在バトル1は有用人物でバトル2はアイドルだという状態になっているのでこの時点ではもう1台しかアイドルサーバーがないのでそれをバトルインフォンのアプリケーションの中で自信をフォークすることによって新しいバトルサーバーを1台起動することによってこの状態を見ながらバトルサーバーをフォークしていきますということができますさらに右の図になるんですけれども今度はバトルサーバーがユーズドになってもすでに2台あるのでバトルインフォンサーバーのほうが不要なバトルサーバーを今度はキルをして殺すというような動作がありますこれが先ほどフォークした時のでも出てきた魔法児がブワーッとなって最終的に石の塊をドーンとできたのがフォークの部分で最後に爆発して消えたというのがバトル1の部分になりますこうすることでアプリケーションの内部の状態を持ちアプリケーション自信で素早くリソースの要求ができるという意味で自律的なオートスケーリングというような意味になっているとお考えください最終的にラックによるゲーム環境なんですけれどもこちらのようになっていますラックの方でラックブートシンクというコマンドを叩くことによってまずシンクサーバーが立ち上がってオーケストレーションが始まってこちらの環境が出来上がりますとそれでオーケストレーションを終わると今度はバトルインフォンのプロセスのほうが現在バトルサーバーが足りないという情報がわかるのでバトルインフォメーション自信が今度はオートスケーリングとしてそれぞれのバトルサーバーを必要大数分立ち上げますとこれで自動的にゲーム環境ができるんですけれどもあとはプレイヤーが接続した状況に応じてさらに状態が変わっていくのでその状態に応じてバトルサーバーをキルしたりフォークしたりというような環境が出来上がります最終的にこの環境が不要になったときはラックキルシンクというコマンドをやると繋がっているのでこれをキルすると環境全てを全て一発で削除するという動作もさせることが可能です以上で今回ラックによるゲームの環境の説明は終わりとなるんですけれども総括すると我々が言いたかったことというのは以下のとおりになりますまずサービス管理によるクラウドコンピューティングというのは基本的にはタリス的ですという点です一方ラックは自立的なクラウドコンピューティングを目指して開発されたものですそのために何をしたかと言いますとラックはプロセスモデルをクラウドに遞用しましたということですこれを行うことによって先ほどもちょっと説明したようなフレクティブルな機動かオートスケーリングもオーケストラレーションもそうなんですけれどもあとはプロセス自身が素早くリソースを自分自身の状態を使って供給したりだとかあとはできますしサービスを一切使わないのでここによっていろんな要件に対することができるという部分だとか先ほども説明しましたけれどもラックパイプなどの便秘なプロセス管通信を使うことによってそれぞれのプロセス管で簡単にデータ通信がやり取りということができるというような利点がを得ることができます以上で我々の説明のほうご視聴ありがとうございました