開発、ステージング、本番用サーバについて 第02回 16年08月 / 最終更新：2016.08.09
みなさん、こんにちは。エンジニアの古庄道明です。
前回に引き続き「なぜゲームにおいてクラウドが重要である事が多いのか」を、前回とは少し異なる視点から見ていきたいと思います。
ゲームに限らず、Web関連の開発であればおそらくは
・開発用サーバ(群)
・ステージング用サーバ(群)
・本番用サーバ(群)
の３種類が、最低でも役者として出てくるかと思います。
開発用サーバ(群)については「各local PCにVirtual PC(Vagrantとか)」というケースも多いかと思うのですが、筆者個人の感覚としては「ルールをしっかりとしないと面倒が起きるケースがある」ので、どちらかというと「開発用サーバをちゃんと立てる」方が多いです。
筆者の場合「複数人を１台の開発サーバに同居していただく」ようなやり方ですね。サーバインスタンスのサイズにもよりますが、
とりあえず「困るほど重い」ケースは、今までに起きたことはなかった、と記憶しています。
このあたりはまた少し細かい言及になるのでここでは避けますが、Vagrantを使う場合は「勝手にインストールはしないこと(「ソースコードをpullしたら動かない！」「僕の環境では動いてます！」対策)」というあたりを順守させるようにするとよいかと思われます。
ステージング用サーバ(群)は、おおむね「確認」用のサーバになります。
「誰に」「何を」確認してもらうのか、という(些か政治的な意味を含む)あたりから。ステージング用サーバは「ない」から「数台(筆者の経験だと最高で３台(第一ステージングサーバから第三ステージングサーバまで)」までグラデーションが現場によってあるのですが。
出来たら「１台」は持っておくと心安らかな事も多いのではないか、と思われます。
本番用サーバ(群)は、さらにここから
・DBサーバ
・Webサーバ
が最低限出てくる可能性が高いです
(オールインワンもあり得ますが、よっぽどミニマムスタートでない限り、割とレアケースかと思われます)。
また、ここからさらに
・ロードバランサ
(Webサーバが２台以上の場合事実上必須：DNSラウンドロビンで一端逃げる手もあるけれども、恒久的にその手法のみ、は稀)
・バッチ用サーバ
・画像などのダウンロード専用サーバ
・管理画面用サーバ(＋管理画面用DBサーバ)
・DNS用サーバ
など、いくつかの役割によって分離されていくようなものもありますし、状況によっては「当初は１台のサーバで共存、後で切り離し」
なんていうケースもあろうかと思います。
上述のうち「本番サーバ(群)」については割合と増減が激しく、また「丁寧に増減させた」ほうがコストメリットも高く…
といったあたりは１回目に言及をした通りになります。
それに比べると、開発用サーバおよびステージング用サーバについてはそこまでタイトな要求であることは少ないですね。
ただ、それでも「サーバを用意するのに１週間かかる」となると、場合によっては開発者の手が空いてしまう可能性もあり、些かもったいないので…という意味では、「すぐにサーバが用意できるIaaS」には一定のメリットがあります。
ちなみに「開発用サーバは用意せず、リリース前は直接本番機で開発」というケースも一定数見ていますが。
まぁまぁの確率で「リリース後も開発環境がない」「開発環境を後から作ったはいいけど、開発環境から本番環境にデプロイする手段が決まっていない(のでデプロイが大変)」というケースは割と見ておりますので。
コスト的にもさほど高額になりませんので、開発用サーバ、ステージング用サーバとも、ちゃんと「リリース前に(できれば開発の初期から)」作っておくことを強くお勧めいたします。
さて。
上述を前提にしまして、Web開発全般に言えることになりますが。
開発がよっぽど短期で片付かない限り、或いは短期で片付いてもなお「daemon等のバージョンアップ」という事象が、これは必ず付きまとってきます(注意：メジャーバージョンのアップは、一端議論から外します)。
そうしますと必ず出てくるのが「daemonのバージョンアップをするか？ しないか？」という議論です。
daemonのバージョンアップのうち一定割合は「セキュリティフィックス」だったりします。また、内容によっては「ごくまれな一部機能の一部ケース」だったりしますが、内容によっては「かなりシリアス」だったりもします。
それらを「どうするか？」というのは、確かに些か難しい問題です。
時々「うちでは色々と確認をしているので古いバージョンのままいきます」というご回答を頂戴する(たびにため息をつく)のですが。
もちろん可能性として「全てのセキュリティフィックスの変更を確認して、問題ないことを(場合によってはソースコードレベルでレビューして)確認済」という可能性がないわけではない…と思うのですが、筆者は見たことがないですね。
実際問題、いくつか質問をしても、ちゃんと「技術的に明確な」回答が返ってきたためしは正直ないです。
そうしますと。
もちろん「バージョンアップ翌日にすぐ対応」かどうかは議論が大きく分かれるところだと思うのですが、やはり「daemonのバージョンアップにある程度追随できる手法」は、手持ちで持っておいたほうが「より安心して開発や運用ができる」と言えるでしょう。
「バージョンアップできるノウハウがあり、実績がある」前提で「今回はやめる」という選択肢は、それ自体はあり、だと思いますので。
上述も色々とノウハウや手法があるのですが、IaaSの場合、上述について、今まででは些か「考えられなかったほどにアグレッシブな手法」が存在します。
些か長くなりましたので、次回、その手法について解説をさせていただければ、と思います。
サービス・ソリューション
