ソーシャルアプリ開発者、とくにインフラを担当している技術者の方はシステム構成をどのようにしていますか。
最近の一般的だと思われるシステム構成とソーシャルアプリ開発のインフラ構築時に使える10個のチェックリストをご紹介します。
実際にソーシャルアプリやソーシャルゲームのシステム構成として稼働実績があるシステム構成になりますので参考になるかもしれません。
インフラ構築に使える10個のチェックリスト
- 必要なときにスケールアウト､スケールアップができるか
- トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか
- トラブル発生時に担当者に通知がされ､その障害対応フローやエスカレーションがマニュアル化されているか
- 性能を考慮したハードウエア、OS、ミドルウエア(Apache､MySQL)構成、設定になっているか
- メンテナンス時間を最小化できるか
- ログファイルをいつでも参照、見える化（グラフ化）できるように管理出来ているか
- サーバの状態を常に把握できているか(全体PV､各ページPV,日毎､時間毎）
- WEBサーバ、キャッシュサーバ、ＤＢサーバ、踏み台サーバの分離、機能の明確化ができているか
- バックアップ・リカバリの方法は確立されているか
- 監視用アプリケーションは正しく、漏れなく設定されているか
1. 必要なときにスケールアウト､スケールアップができるか
自前でマシンを用意する場合、ある程度余裕を持ったインフラを構築しておきたいものです。しかし多くのサービスでは必要最小限ではじめたい。という声があるのも確かです。（予算もありますし）
これがクラウドサービスを利用した場合、クラウドの一番のメリットと言える内容です。それぞれの意味を把握しておくと良いことがあるかもしれません。
- スケールアウト(Scale Out) ･･･ 稼働する仮想サーバの台数を増やす機能
- スケールアップ (Scale Up)･･･ 稼働するサーバ1台の性能をあげる
多くのクラウドサービスではこのスケールアウト、スケールアップは対応しています。その方法については開発しているサービスに合わせて手順書化しておくことがベストです。
ref:クラウドでよく言われる「スケールアウト」の反対の言葉って何だろう？
2. トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか
障害対応やバグ対応でもっとも大切なことは「障害が発生したときの原因を突き止めること」です。
問題が分かってしまえば解決するための対策を行うことはそんなに難しいことではないですし、いつ解決するのかを見積もることも比較的容易に出来ます。インフラを構築する時は、この原因を突き止めるための材料（ログ、発生手順、システムの挙動、エビデンス）をできるだけ多く、楽に集める仕組みが必要ということを意識して、インフラを構築するべきです。
3. トラブル発生時に担当者に通知がされ､その障害対応フローやエスカレーションがマニュアル化されているか
多くのシステムでは有料、無料を問わず、使い慣れた監視システムやパッケージ等のソフトウェアを導入していると思います。監視システムにより障害を検知し、関係者にアラートできることは当たり前ですが、障害発生後の
- 1次受付け
- 問題の切り分け
- 判断をする役割、管理者の判断の有無(ビジネス上の)
- 担当者割当
が重要になります。障害が発生したときは、少なからず現場が混乱した状態になることが考えられますので落ちついて対処するためのルールやマニュアルを問題が起こる前に決めておくべきです。
4. 性能を考慮したハードウエア、OS、ミドルウエア(Apache､MySQL)構成、設定になっているか
アプリケーションの性質に合わせて、特にOS、ミドルウェアの設定は本番サービス開始までに必ず見直しをするべきです。
Apacheの設定ファイルやPHPの設定ファイルが環境によって異なっていたり、開発環境の設定になっている場合がよくありますので注意が必要です。Web#1とWeb#2は同じ役割のはずがApacheの設定やPHP.iniの設定が違う・・・は避けたいですね。
5. メンテナンス時間を最小化できるか
システムを長時間稼働させるように構成されたシステムにおいても、メンテナンスは多くのサービスで必要になります。ソーシャルゲームの場合、メンテナンス中は利用者が「アクセスすることが出来ない = 売上がない」、状態であるため可能な限りメンテナンス時間を最小化させる方法を考えるべきです。
- メンテナンス中に実施している作業は本当に必要なのか・・・サービス停止しなくても良いのでは?
- 夜間等のバッチ処理でできるのではないか
- ジョブの順番や時間帯の変更は可能か
等の今より最適化することは常に考える必要があります。可能なら無停止アップデートができるのかを検討すべきです。
6. ログファイルをいつでも参照、見える化（グラフ化）できるように管理出来ているか
ウェブアプリケーションやソーシャルアプリでは、Apache、MySQL等のミドルウェアのログ、システムログ、アプリケーションログと見なければいけないログが散らばっており、さらにサーバによっても分散していると思います。開発や運用に多くの情報とヒントを提供するものがこのログファイルです。ログファイルをいつでも、すぐに参照できるように管理(集約、集計)することはとても重要です。
サービスが運用フェーズに入った段階でも、警告やエラー情報、タイムアウト等の異常をすぐに見つけ、原因を探す糸口として活用できるようになっているのかをチェックします。
7. アクセスの状態を把握できているか(全体PV、ページPV、日毎、時間毎、リソース）
サービス提供しているウェブサイトのアクセス解析を導入しているのか、また導入済みのアクセスログから自分たちに必要な数字を把握できているのかはとても重要なことです。直接利用者の動向を把握することが出来るツールになるため、自サイトのターゲットと実際の利用者の行動を把握するために活用できるような仕組みになっている必要があります。
8. WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか
Webアプリケーションの場合、役割によってサーバを分けたりパフォーマンス向上のために分割したり、をよくやります。ボトルネックになりやすいDB(マスタ)やスレーブDB等、機能の明確化をメモ書きしておくことで
- システムの全体像を把握したり、
- 将来の拡張性を考える
- 運用保守の補助資料として利用
- チーム内で情報共有（どのようなインフラになっているかを説明出来る）
ができます。役割分担（機能分担）を明示することはとても重要になります。
ソーシャルアプリ開発プラットフォーム(クラウド環境)
ソーシャルアプリ開発プラットフォーム(クラウド環境)/開発・ステージング環境
9. バックアップ・リカバリの方法は確立されているか
アプリケーションやDBのバックアップを実施することは比較的容易に出来るのですが、
- リカバリにどれくらいの時間が必要なのか、
- 正常にリカバリできるのか
ということは問題になるのではないでしょうか。
バックアップ・リカバリについては本番機と同等のマシンでリハーサルを実施しなければ正確なリカバリ時間や問題点は見えてこない場合が多々あります。(見積だけでは理想値になりやすく、試験をしない場合、障害が起こったときに想定外のトラブルや取り返しの付かない問題が発生すると考えるべきです。)
どうしても開発中は開発が優先されるため、バックアップ・リカバリは後回しにされる場合がありますが、利用者データや自分たちのシステム保全はとても大切なことなので実際にやってみることはとても重要になります。それが運用マニュアルとして記録されているとベストです。
10. 監視用アプリケーションは正しく、漏れなく設定されているか
システムのリソースやサービス監視用の専用ツールはとても高機能で便利に利用しているサイトが多くあります。自分たちのアプリケーション特性にあったチューニングや設定ファイルになっているのかを確認すべきです。デフォルトのままというありがちなミスをしないように注意する必要があります。
ソーシャルアプリ、ソーシャルゲーム開発のプラットフォームを構築するインフラエンジニアは表に立って活躍する目立つ存在ではありませんが、縁の下の力持ちな人材です。ソフトウェア開発期間よりももっと長い期間、運用を支える大切な基盤環境を構築しなければいけません。
インフラに関する10個のチェックリストをあなたの開発チームでも確認してみてください。
これ以外にも大切なチェックはあると思いますので教えてもらえればインフラエンジニアのスキルアップに繋がりますのでご意見をお待ちしています。
