変化に強いインフラ作りに取り組んでいます。Argumentsについては、こちらのインタビューを参照してください。近い形でインフラを構築してきました。近いインフラを用意することで変化に強いインフラ作りが出来ると考えているからです。起動するのは通常数分かかります。数秒でサービスがリクエストを捌ける状態まで立ち上げることが出来ます。リクエストが急増する時は、数分待っていたら間に合わないということも多いのですが、この起動の速さの差により、安全を期して余裕をもたせすぎた構成にする必要がなくなります。予備のマシンを用意して置く必要はありますが、それはサービス間で共有できるので、トータルで用意しなければならない予備のマシンの数は減らすことが出来ます。入ったコンテナを用意することが出来きます。書くだけで実現できます。これと同様なことは実現できますが、1年ぐらい経つと同じインストール方法ではインストールできなくなってしまったりして、設定ファイルのメンテナンスが必要になってしまいます。その方法でインストールができなくなっていたとしてもイメージになっているので起動させ続けることが出来ます。イメージを使うことが出来ます。入っているだけのコンテナに絞って手元で用意できるのはローカルのPCに対しても負荷が少ないですし、気にする部分が減ります。移動させることが可能です。日本に提供されていなかったり、独自のサービス、ElasticsearchなどのMiddlewareが建てられなかったりします。カスタマイズする必要があります。書くのと同じかそれ以上かかってしまいます。出来るコンテナは一個のプロセスだけを動かすシンプルな構成を推奨しています。そのため、一つのサービスで複数のプロセスが必要な場合、シンプルな構成で作られたコンテナを組み合わせて利用することになり、より疎結合で変更がしやすくなります。これにより大きな物が出来る「Unixという考え方」に近いことを実現出来ます。仮想化の粒度が大きく異なります。したいと考えた場合にどうやってデリバリーしていくのかを取り扱いたいと思います。以下の前提条件から比較していきたいと思います。影響を及ぼさないか注意しなければなりません。コンテナの場合、一つのコンテナとして閉じているため、そのコンテナ内だけに集中して作業することが出来ます。起動を待ってから、入れ替える形になります。作ったり消したりする際に、非常に大掛かりな作業になります。プロセスと同じ方法で入れ替えることが出来ます。普段から利用しているプロセスをそのまま使えるのは作業者も、安心してリリースすることができます。含めてローカル環境で組む必要があります。実行が必要になり、手間が多いです。取り組むことが出来ます。比べて手間が少ないです。側のチームが主体となって変化を作ることが可能です。コンテナが仕事をする構成です。して作り直しています。側でも積極的に試しやすいという点と入れ替えやすいという点が大きな要因になっています。側が見に行く必要がなくなります。書いてリリースしたいと言う場面がでてきました。開発に集中することが出来ます。いつまでもインフラチームの作業のままです。なることでマシンの部分についてより意識しなくてもよくなってきています。入れ替えるのは工数的に行いにくい状況でした。最新を使うようになりました。側のエンジニアで作成されたりしています。側のエンジニアが主体で書かれています。用意するといった部分については、インフラチームが行っている状況です。ようなクラスタリングする仕組みを作ることで現在できていない部分が解決出来ると思っています。用意したりも要らなくなります。来る機会が増えると感じます。インフラチームは、「変化に強いインフラ」作りに取り組んでいます。環境を提供しようと努力しています。そのために、クラスタリングという一つの大きなインフラを作ることで、達成出来るのではないかと考えています。私たちは使い続けると思います。やめるのか?インフラを全く意識しない環境が低コストかつ、一瞬で用意することができればいつでも乗り換えると思います。使う事自体が目的ではないからです。それが実現可能そうなものは現れていないと考えています。変化に強いインフラがすべて実現かというとそうではありません。今でも新しくサービスをリリースする時はどうしてもインフラチームが作業することが多々あり、まだ完全に実現ができている状態ではありません。インフラチームでは、この変化に強いインフラを作るために日々改善に取り組んでいます。BlogWantedlyのエンジニアによる、テックブログです。開発者向け技術情報を中心に発信しています。(ウォンテッドリー)を展開しています。