変化に強いインフラの取り組み（3）
自動化
運用／保守となる作業はできる限り共通化、自動化していきましょう。そうすることで、余った時間はどんどん新しいことにチャレンジできますし、人的ミスも減ります。そのため同じ作業はどんどん機械にやらせるようにしましょう。自動化の仕組みはデベロッパーの生産性向上に大きくつながるので、インフラチームは改善するために日々調査、検証、開発を繰り返しています。
Deployment
なるべくデプロイ方法は言語やフレームワーク依存をなくし共通化（docker run）しましょう。
Logging
新しいサービスが追加されても、特別な設定を行うことなく標準として自動でログを抽出するようにしましょう。
Monitoring
新しいサービスが追加されても、特別な設定を行うことなく標準としてモニタリングするようにしましょう。
Dashboard
モニタリングと同様にダッシュボードにも追加するようにしましょう。
Service Mesh／Dependency Graphs
どのアプリケーションがどういった連携をしているのかを視覚化させましょう。
リポジトリ
Wantedlyでは直近の開発状況から以下のルールができてきました。
ルールが決められていくと新しくサービスを作る際に既存のリポジトリが参考になるため、挑戦しやすくなります。特徴的な部分をまとめました。
- The Twelve-Factor Appな構成
- The UNIX Philosophyから大きなモノリシックにしないように
- リポジトリ直下にDockerfileを配置し、いつでも出せる状態
- script/bootstrap、script/serverどの言語でも共通の実行方法
- doc/ドキュメント置き場
- healthcheck 死活監視用エンドポイント
Kubernetes導入
2016年からはさらに一歩踏み込み、Kubernetesを用いてより効率的にインフラとデリバリーを抽象化させ、デベロッパーが自由にリリースできる仕組みに取り組んでいます。
Kubernetesは複数のサーバーをまとめてクラスタリングを行い、効率よくインフラとコンテナのスケジューリングをしてくれます。
これまでの取り組みから、少しずつAPIを利用してインフラを操作したり、コンテナを作成したりとセルフサービス化が進んできました。しかし、アプリケーションのサーバーセットアップをする際には、デベロッパーはインフラチームに依頼する必要がありました。理由は、そのままサーバーを立て、コンテナを立ち上げただけでは、プロダクトとして保障された品質までたどり着けないからです。具体的には、ログの設定や監視ツールのインストール、その他社内ツールをインフラチームが設定する必要がありました。そのことにより、サーバーが準備できていないと結局、後の工程にあるLoad BalancerやDNS等を設定することができず、APIで操作できるようにしていても活用することはなかなか難しい状況でした。
Kubernetesは、デベロッパーが好きなように自分のサービスを建てられるようにしてくれます。このことにより私たちは小さいサービスを出しやすくなりました。
運用は間違いなく難しくなりますが、より変化に強いインフラを実現するためのメリットのほうが大きいため、私たちはこの流れを止めずマイクロサービスを推進しています。マイクロサービスを行う一番の理由は、1つのことに集中することによる技術的優位性を出せる点、必要なくなったら簡単に廃棄可能な点で、今までにないくらい変化を前提としたインフラの実現が可能になります。
- 他のサービスに依存することなく1つのことに集中できる
- 最適なメモリサイズ
- 並行処理、並列処理
- 最適な言語
- 最適なミドルウェアの選択
- 役割が明確なため影響範囲が限定され必要なくなったら廃棄できる
1つのことに特化した環境が簡単にできるからこそ小さなサービスが生まれやすくなり、最終的に技術的優位なサービスが集まった大きなプロダクトが見える状態になります。さらなる変化に強いインフラへ進化させるため、Kubernetesの導入に至りました。
Wantedly PeopleでのKubernetes事例
Wantedly Peopleは9つの言語で動く十数個のマイクロサービスから実現しており、現在でもどんどんサービスが増え拡大し続けています。その中にはAPIや機械学習、画像処理、検索サーバーなど、用途ごとに複数のサービスが存在しています。いろいろな言語やフレームワークを利用していますが、全てのサービスが同じ運用方法になっています。
- Test → Build → Deploy
- Console
- Scale
- Log
そして、リリース方法やQA環境などの構成を柔軟に変更したり、追加したりできます。また、既存のWantedlyのinternal APIが利用できるようにAPI Gatawayの基盤も構築しています。
おわりに
アプリケーションのルールや自動化、Kubernetesなど、インフラチームでは「変化に強いインフラ」を実現するためにセルフサービス化に取り組んでいます。最後に、どこまでセルフサービス化を実施しているのか、図にまとめました。
これまで年間5つほど増えていたリポジトリが4倍近くのスピードで増加するようになり、多くのサービスが生まれるようになりました。
もちろん、デベロッパーの協力なくしてこのKubernetes導入は実現することはできません。今回ご紹介したもの以外に、社内勉強会やドキュメント、サポートなどを行っております。インフラチームがどれだけ新しい取り組みや流行りのカッコいいインフラを構築しても、最終的にCode wins Argumentsを可能にできないようであれば施策は全て失敗に終わります。全てのエンジニアに定着させるまでにはまだ至っておりませんが、これからもインフラチームは変化に強いインフラを目指し、エンジニア全員がCode wins Argumentsを実施できるインフラの実現に向けて日々取り組んでいきます。
次回は、例として架空のサービスを実際に作る上での手順をご紹介します。
