スタートの経緯・挨拶

最近では個人でWebサービスを作る方も増えていますが、アクセスが増加してくると確実に問題となってくるのがパフォーマンスや可用性の問題です。ある程度まではアプリケーションの修正することでパフォーマンスを向上させることはできますが、やはり限界はどこかできてしまいます。

しかしながら、「⁠どうやってシステムを増強していけばいいのだろう」という知識に関しては世間にあまり出回っていませんでした。そのようなときに参考になるような技術や考え方を提供したいという思いから、本連載を執筆させていただくことになりました。

本連載においては、さまざまな技術を用いて、システムの設計・構築するためのさまざまな方法を提供していきたいと思います。

システム拡張時の手段と問題

システムの規模が大きくなればなるほど課題となってくるのが、どのようにシステム全体を増強していくかです。

システムの増強において方法は2つあり、一般的にはスケールアップ型・スケールアウト型と呼ばれています。

スケールアップ型とは1つ1つのサーバのCPUやメモリの性能が高いものにリプレースをしていく増強の方法で、ある程度の規模までは効果的ではあります。しかしながら、ハイエンドのサーバになってくると価格も大きくなることや1台のサーバの役割が増えることによるメンテナンス性の低下などが発生してきます。

スケールアウト型とはGoogleのシステム（Google File Systemなど）に代表される、複数台サーバーでシステムを構成する増強の方法です。1台1台のサーバを単価の安いものを使用し、高速かつ大容量のデータをさばくことができるように設計されています。

理想的な型のように見えますが、システムの構築が困難なため完全に分散型のシステムにするのはやはり難しいようです。

求められる可用性

アクセスの増加とともに変化してくるのが、求められてくるシステムの可用性です。会員数が1,000人のサービスが10分間停止することと、会員数が100万人のサービスが10分間停止することを比較してみるとわかりやすいと思いますが、当然ながら利用者が増えていけば増えていくほどシステムは停止しづらくなり、ましてやデータが消えてしまうことなんてあってはならないことになってきます。

また、無料で提供しているサービスと、ユーザに課金をして動かしているサービスによっても求められてくる可用性が変わってきますので、SLA（Service Level Agreement）に沿ったシステム設計をすることが必要となってきます。

メンテナンス性を考慮した設計

システムの運用というわりと地味なイメージもあり軽視しがちですが、運用を考えた設計になっているかどうかでその後のメンテナンス性が大きく変わってきます。当然、システムといえど完全に何もしなければ止まってしまうこともありますし、壊れてしまうこともあります。H/Wの故障による問題や、人為的なミス、悪意のある攻撃など検討すべき点は多々ありますので、想定しうる限りのリスクヘッジをとれるようにしておきましょう。

引き継がれていくシステム

システムアドミニストレータとしてシステムを設計・構築したとしても、その台数が増えるに従って1人だけで面倒を見ていくわけにはいきません。Webサービスに火がついてアクセスが増えること自体も突然起きうることなので、ある程度までは柔軟に対応できる体制をとっておくことが必要となってきます。

実際に、1人でシステムをつくって運用を続けるような体制が長く続いてしまうと、知らない人では把握できないようなシステムになってしまう可能性があります。小さな問題でも「とりあえずこれでいいか」という判断で解決していくことにより知らない人によってはどんどんと難解なシステムになってしまいます。

実例としては、Symlinkの多用やPermissionを甘く設定するというようなことが挙げられますが、やはりシステムを設計する以上はある程度他の人でも想像ができうるような型をしておくほうが良いでしょう。

また、システムを設計・構築した際は、その内容をドキュメントとして残しておくことが大事です。H/Wの情報などが詳細に記載されているものがありますが、実際にはそれだけでなく、各サーバで動いてなければいけないdaemonや障害時の対応方法なども記述しておくべきでしょう。

さらには、サーバ個々の情報だけでなくシステム全体でみてシングルポイントとなりうる部分はどこなのか、ということが把握できるような全体像も作成しておいたほうが良いです。とくにレガシーなシステムを運用することになると、設計内容どころかサーバが何台存在するかすらもわからないようなケースも発生します。全体像を把握するためだけでなく、原因不明の障害が起きた際、障害となっているポイントの切り分けが確実に速くなります。BTS（Bug Tracking System）などを使って、いままで起きたシステム障害を管理するのも情報を残すという意味でも良いのかもしれません。

本記事で使用するサーバ構成

紹介させていただく際のサーバ構成ですが、以下の構成を基準にして紹介していく予定です。

上記の通り、一般的な構成で進めていきます。使用するためのWebサーバなどはその都度紹介をしていきます。また、本連載においてはサーバの構成などによるシステムの設計を中心に進めていくため、サーバルームあんどの話に関しては割愛させていただきます。

今後の内容

今後の内容では、レンタルサーバから始めたサービスを例に挙げて、段階分けてをシステムを増強していく方法を紹介していく予定です。取り上げる技術に関しては、オープンソース系の技術やアプライアンス製品も含めて紹介させていきます。

まとめ

まずはシステム設計に関する問題提起を中心にさせていただきました。

システムアドミニストレータを経験されている方にとって、あたりまえに感じる方も多いでしょうが、改めて見てみるとできそうだけど難しくて着手できていないこともあるのではないでしょうか。

次回は、システムを増強の方法をより細かく絞って紹介をしていきたいと思います。