Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie ゲームインフラコンテナ実践導入
Ähnlich wie ゲームインフラコンテナ実践導入 (20)
ゲームインフラコンテナ実践導入
- 2. 自己紹介 ・田宮 弘樹（たみや ひろき） ・ファイブスターズゲーム（株）でチーフエンジニアをやっています ・担当範囲はインフラ、サーバープログラム、アプリプログラムなど ・サーバープログラムが一番得意
- 10. サーバー構成 ・GCP上のComputeEngineでCoreOSを使用 ・ロードバランサ（GCP） ・Webサーバー（Nginx）x１台 ・Appサーバー（Unicorn, Ruby on Rails 4）x１台 ・MySQL5.6（マスター・スレーブ構成。※スレーブはバックアップ用）各１台 ・コンテナ管理はdocker-compose
- 11. Nginx Unicorn サーバー#1 サーバー#2 サーバー#3 データコンテナ MySQL Master データコンテナ MySQL Slave GCPロードバランサ Cloud StorageへBackupデータコンテナ docker compose docker compose HTTPS HTTPS
- 12. datastore: container_name: data mem_limit: 268435456 build: datastore tty: true restart: always nginx: container_name: web mem_limit: 268435456 restart: always build: nginx ports: - '80:80' - '443:443' volumes_from: - datastore links: - rails_blue - rails_green rails_blue: container_name: app_blue mem_limit: 4294967296 restart: always build: . ports: - '3000:3000' tty: true environment: RAILS_ENV: production MYSQL_ROOT_PASSWORD: '********' DATABASE_URL: mysql2://****:********@10.240.0.3:3306 UNICORN_WORKER_PROCESS: 8 UNICORN_PORT: 3000 volumes_from: - datastore rails_green: container_name: app_green mem_limit: 2147483648 build: . ports: - '3001:3001' tty: true environment: RAILS_ENV: production MYSQL_ROOT_PASSWORD: ‘********’ DATABASE_URL: mysql2://****:********@10.240.0.3:3306 UNICORN_WORKER_PROCESS: 8 UNICORN_PORT: 3001 volumes_from: - datastore
- 13. datastore: container_name: data mem_limit: 268435456 build: datastore tty: true restart: always nginx: container_name: web mem_limit: 268435456 restart: always build: nginx ports: - '80:80' - '443:443' volumes_from: - datastore links: - rails_blue - rails_green rails_blue: container_name: app_blue mem_limit: 4294967296 restart: always build: . ports: - '3000:3000' tty: true environment: RAILS_ENV: production MYSQL_ROOT_PASSWORD:'********' DATABASE_URL: mysql2://****:********@10.240.0.3:3306 UNICORN_WORKER_PROCESS: 8 UNICORN_PORT: 3000 volumes_from: - datastore rails_green: container_name: app_green mem_limit: 2147483648 build: . ports: - '3001:3001' tty: true environment: RAILS_ENV: production MYSQL_ROOT_PASSWORD:'********' DATABASE_URL: mysql2://****:********@10.240.0.3:3306 UNICORN_WORKER_PROCESS: 8 UNICORN_PORT: 3001 volumes_from: - datastore
- 14. 旧 Appコンテナ 新 Appコンテナ Port:3000 Port:3001 Nginx 80/443番を 3000にProxy 新 Appコンテナ 新 Appコンテナ Port:3000 Port:3001 Nginx 80/443番を 3000にProxy 旧→新 Appコンテナ 新 Appコンテナ Port:3000 Port:3001 Nginx 80/443番を 3001にProxy １）デプロイ用の Appコンテナ起動 ２）3001にProxyし直し 旧コンテナを更新 ２）再度3000にProxyし直し 3001のコンテナを停止 デプロイ デプロイ ストップ
- 17. 特に問題なく稼働しています
- 21. データ コンテナ MariaDB Master データ コンテナ MariaDB Slave APIサーバー コンテナ データコンテナ マッチングサーバー コンテナ データコンテナ HAProxy コンテナ HAProxy コンテナ バトルサーバー コンテナ データコンテナ HAProxy コンテナ データ コンテナ Redis Cluster Master データ コンテナ Redis Cluster Slave Fail overReplication http:// ws:// ws://
- 28. 苦労したところ
- 30. RedisCluster Master node#1 RedisCluster Master node#2 RedisCluster Master node#3 RedisCluster Slave node#4 RedisCluster Slave node#5 RedisCluster Slave node#6 etcdクラスタ ノードごとの IPアドレスを記録 起動時に 対象ノード管理ファイル node.confを新しいIPで更新 node.conf node.conf node.conf node.conf node.conf node.conf IP更新 IP更新 IP更新 IP更新 IP更新 IP更新 Redis Cluster 3.2.1
- 32. これにて構築完了
- 35. まとめ
- 38. ご清聴ありがとうございました
Hinweis der Redaktion
- みなさんこんばんは。 私からは、ゲームインフラコンテナ実践導入ということで 皆様の酒の肴となるお話になればと思います 私の前にとてもスマートなLTをされてしまいましたが、 私からは、現場レベルでのコンテナ導入についての まあ、なんというか、経験をお話する形になるかと思います。 なので、もっと泥臭い。 現場レベルでのお話、現実的なお話になるかなと思います（笑）
- まずは、簡単な自己紹介から
- 今日お話ですが、 自社ゲームアプリでコンテナを試用は、GCPですが、 大手ゲームパブリッシャー受託開発案件でのコンテナ導入の項はGCPではなく国内クラウド業者での事例となります。 で、最後にまとめという流れになります
- まずは自社ゲームアプリでコンテナ活用について、 えー、若干のアプリの宣伝も兼ねてご紹介したいと思います
- このゲームは弊社がR&Dとして開発したフル3Dのレールシューティングゲームで、 タイトルは、ロストニアと言います。 いわゆる雰囲気ゲーに近いものですかね。 七つの大罪をテーマにした世界を、少女が駆け抜けるというゲームです。
- 基本的に、少女は攻撃をする術というものは持ち合わせておらず、 プレイヤーは少女を守護する堕天使という位置から様々な敵の襲撃を乗り越えなら進めていきます
- 是非、ダウンロードしてみてください。。。と言いたいところなのですが、 現在、カナダ、オーストラリア、イギリスといった限定的な地域でのみ配信しており、 日本での配信はまだ行っておりません。
- 自社R&Dのゲームということで、サーバー側もR&Dとしてトライするということで dockerコンテナを使用してみました。
- サーバーで管理するデータは、課金履歴とレシートの検証、及び、 ユーザーサポートのための補填データ（いわゆるプレゼントボックスにあたるもの）です。 アプリの性質からアクセス数、頻度ともにそれほど多くないだろうということが予想できましたので、 シンプルな構成にしました。
- 構成はこんな感じです。 サーバー構成はGCP上のCompueteEngineを使用し、CoreOSを使用しています この構成からわかるように、割と規模の小さい構成ですので、 コンテナの管理にdocker-composeを使用いたしました。
- 構成を簡単に図にするとこのような形になります。 この構成だとロードバランサを使う意味はあまりないのですが、 念のため、将来的な拡張性を考えて、入れています docker-composeはマルチホスト間のコンテナのリンクには対応できませんから、 必然的にサーバー#1やサーバー#2,3といったホスト単位での構築となります。 dockerコンテナ間でlinkを指定している部分は、サーバー#1のNginx->Unicornの部分のみで、 サーバー#1とサーバー#2の接続はサーバー#2のホスト情報をdocker-composeに直に記載してあります。
- これは先ほどのサーバー#1にあたるdocker-composeの設定ファイルです。 パスワードはアスタリスクで伏せてあります。 サービスディスカバリーなど使用していませんので、接続先ホストのIPアドレスも直に記述しています。 このように、docker-composeの設定はYAMLで記述でき、ポート情報や環境変数、リソースの使用制限、 再起動時の挙動などを一通り指定することができます。 シングルホスト構成であれば、ほぼこれでこと足りるかと思います。 例えば、restartではコンテナが落ちた時の振る舞いを設定できますし、 mem_limitなどでは使用メモリを制限したり、ボリュームとしてアタッチするコンテナであったり、 リンクするコンテナなども指定できます。
- なお、この青と緑の枠はローリングアップデート用の設定です。 docker-composeのYAMLにはこのように、rails_blueとrails_greenという２つのコンテナ情報を記述しています。 rails_blueはポート3000、rails_greenはポート3001として 予め、nginxのconfigの方に80番と443番からのアクセス時にリバースプロキシーするように登録してあります。
- Appコンテナのデプロイの手順は大まかに説明しますと、こんな感じになります。 ・ポート3001で待ち受けるAppコンテナを新たに立ち上げます。 ・立ち上がったら、ポート3001(rails_green）に一旦トラフィックを切り替えます。 （これはnginxのコンフィグを書き換えてリロードします） ・次にポート3000にあたるrails_blueコンテナを落とし、新しくしたものを起動します。 ・ポート3000のコンテナの再起動が完了したあと、nginxのコンフィグを元の3000に通していた設定に戻し、リロードします。 ・ポート3001（rails_green）をシャットダウンします Blue/Greenを交互に切り替える、ポートをインクリメントしていくなどの方式もありますが、 どちらも、その状態を管理する必要が出てくるので、3000>3001>3000と戻すことでこの管理をせずに済むようにしてあります。 という流れになります。
- 次にMySQLのコンテナですが、MySQLサーバーコンテナとbusyboxを使ったデータコンテナで構成しました。
- MySQLサーバーコンテナは、my.cnfを設定したものをビルドしてコンテナイメージです。 busyboxコンテナはmysqlのdatadirの保存先として使用し、このコンテナはMySQLサーバーコンテナからボリュームとしてアタッチされます。 バックアップの時は、busyboxの中にあるdatadirを丸ごと固めて、ホストOSに保存し、それをCloud Storageに転送しています。 busyboxをデータコンテナとして使用する理由は２つあって、 ・仮にMySQLサーバーコンテナがダウンした時に、一緒にdatadirの中身も失われてしまうリスクを避けるため ・ホストOSの環境を汚さないという点 という点ですね。
- Lostniaというアプリは大体こんな感じで、特に問題もなく安定稼働している状況です。 もともと、R&Dでスタートしたプロジェクトでしたので、新しいここみの一環として インフラにコンテナ使った事例となります。 docker-composeは導入が非常に簡単なので、 あまりつまづかずにすんなり導入できると思います。
- 次に、コンテナを大手パブリッシャーの受託開発案件で導入した話をしたいと思います。 こちらはプロトタイプの開発での事例ということになります。 内容については、NDAに触れる部分がありますので、ちょっとご紹介はできないのですが、 こちらの案件では、全面的なコンテナベースのインフラを構築したものなります。 この事例はクライアントがいる案件で、初のコンテナ導入ですので、とてもチャレンジングでした。 今回のお話の本丸はこちらです。
- 構築するにあたり、商用を意識するということで行いました。 つまり、マルチホスト構成です。
- Lostniaのケースとは打って変わった構成です。 まずはCoreOSのクラスタをしっかり構築しています。 クラスタ全体の情報を管理するためのetcd2を、３台マスター専用として立て、他はそのproxyとして参加としました。 サーバー側のプログラムには、より実行速度とメモリ効率のよりプログラム言語、そして何よりdockerと相性が良いGo言語を採用することに。 これは以前、ブラウザゲームをRails4で組んだのですが、メモリの消費が富豪的でサーバーコストが肥大化したことがありましたので、 速度的にもネイティブとして実行できるGO言語を選択しました。 また、バトルサーバーはリアルタイム通信を要求するものでしたので、WebSocketを使用し、クライアントとのデータのやり取りには FlatBuffersを使用しています。
- 先ほどの構成をざっくり図にするとこのような形になります。 詳細まで説明していると、時間が足りませんので、主要な部分だけ。 App／マッチング／バトルサーバーコンテナがいるホストにはHAProxyコンテナも同居させ、 そのHAProxyを介してDBやRedisにアクセスするようになっています。 RedisClusterのマスタは落ちるとSlaveが自動的にマスタに昇格するようにしていますが、 この時のどのノードがマスタなのかをHAProxyで管理することにしたのですが、 これを実現するためには解決しなければいけない問題がいくつかありました。
- まず、ホストをまたぐコンテナをどう繋ぐか？です。
- docker-composeではdockerのlink機能を使ってコンテナ間の接続していましたが、 別ホストにいるコンテナに繋ぐことはできません。
- さらに、dockerコンテナは起動されるまでIPアドレスが確定しません。 これも合わせてなんとかする必要があります
- 最初に、ホストをまたぐコンテナ間の通信についてですが、 これはflannelを使用しています flannelを導入するとflannel0というネットワークデバイスが出現します。（ipコマンドなどで確認できます） これによりコンテナを起動する時に、flannel0のサブネット内IPアドレスが割てられるようになり、 このIPアドレスを使用してコンテナ間で通信することができるようになります。 これで、ホストを跨いだコンテナ間の通信ができるようになりました。
- 次に、起動の度に変化するコンテナIPをどう管理するか？という点です。 これはサービスディスカバリーの機能があれば対応できます。
- 具体的にはconsulをサービスディスカバリーとして使用しました。 また、これだけですと、consulへの登録／削除は自前で行わなければいけませんので、 dockerの起動／終了を検知してconsulに登録／削除を行ってくれるregistratorも合わせて起動させます。 consulに登録されたサービスは、.service.consulという名前で引けるようになり、 これで自ホスト内のconsulに問い合わせれば、目的のコンテナを発見できるようになりました。 先のホスト間の疎通はflannelで既に可能になっているので、晴れてどのホストにいようとも 目的のコンテナに対してアクセスすることができるようになりました！
- 苦労した点が幾つかあるのですが、 これはその中でも特に苦労した点をご紹介したいと思います。
- 実は、Redis Clusterにはクラスタリング設定をする際、 ドメイン名で設定できないという仕様があります。注）3.2.1現在。 サービスディスカバリーでせっかくドメインで管理できるようになったのにもかかわらず、 RedisClusterだけはIPオンリーなんですね。
- これは、どうやって解決したかと言うと、 こんな風に頑張りました。 etcd2でクラスタ構成を記録しておき、コンテナが再起動する度に、 クラスタ管理情報である、node.confを動的に書き換えて起動するという、かなーり泥臭いことをしています もしRedisClusterにドメインが使えていたら、この対応がまるっと削れていた部分です。 これは非常に複雑になりました。 ちなみに、こんなことしなくてもいい方法があるよ。ってのをご存知の方がいましたら、 後でこっそり私に教えてくださいw なお、MariaDBの方は、ドメイン指定ができますので、 別段話すこともないかなと思い、割愛いたしました。
- コンテナのデプロイですが、 これにはfleetを使用しています。 構築ツールはAnsibleを使用していまして、 Ansibleからfleetctlを使ってデプロイします。 各サーバーは幾つか依存するコンテナもありますので、 関連のあるコンテナごとに振り分けていきます。 振り分けは、あらかじめマシンごとにmetadataを設定しておき、 この情報を元に、デプロイしていきます。 例えば、apiサーバーをデプロイする場合は、metadata=apiに対して、と行った感じです。
- これで、なんとか目標の構成通りになりました。
- で、ぶっちゃけコンテナっていいの？って話なんですが、、、
- 私個人の感想としては、主なメリットとデメリットはこんな感じかと。 やはりDBのクラスタリングが大変。 クラスタを初期化するために、期待する数のコンテナを立ち上げる必要性があるとか、 そういった部分ですね。 立ち上がりさえすれば、クラスタリング構成が正常に動作するように 調整する必要がありますので。
- 先の例ですと、RedisClusterはコンテナ化する方が大変でしたので。 コンテナである方が都合が良いものとそうでないものがあると思います。 従って、適材適所で使っていくのがいいのかなと思っています。
- と、ここまででいろいろお話させていただきましたが、 フェイルオーバー、スケーリング、ロードバランス、サービスディスカバリー、ローリングアップデート などなどをKubernetesでカバーできますので、 本当に一からコンテナベースでインフラを組む場合は、頑張ってくださいって感じになりますね（笑） なので、私は今後はKubernetesを使っていくことを考えています。 なんか、Kubernetesがどれだけ良いかみたいなLTになってしまいましたけど、 まあ、１から組んだ苦労があったからこそ、Kubernetesの有り難さを実感できたのということです。 短い時間で、説明しきれなかった部分がもあり、駆け足でしたが、 私からは以上となります。
- ご清聴ありがとうございました。