ツインスパークの開発・運用技術
ツインスパークの「ベスト・プラクティス」
Web開発・運用に「正解」はありません。 2つとして同じ「サービス」はなく、様々な条件により、常に適切な解は異なります。 こうすれば必ずうまくいく、といった方法はないのです。 しかし、成功に近づくための、知識と経験に基づく技術上の「ベスト・プラクティス」ならあります。 私たちツインスパークの提供できるベスト・プラクティスの一端をご紹介します。
1.開発技術
Web開発ではコスト感覚が大切です。 ユーザに対しては無料で提供されることが多いWeb上のサービスにおいては、高価なハードウェアやソフトウェアを利用していては、たとえ高機能なサービスが実現できたとしても十分な運用は行えません。 とりわけWebでは、LAMPなどとも呼ばれるフリーソフトウェアや、それを動かすための 低価格なIA32サーバの利用が盛んです。 一方で、ルータ・Firewallなど、 専用ハードウェアの利用も広く使われています。 これらの適性とサービスを 鑑みた上で、バランスの取れたソリューションが必要です。 ツインスパークは、サービスの成長過程に合わせた、適切な技術の利用をご提案いたします。
○実際の開発では
以前ツインスパークで手がけた、ユーザの多いコミュニティサイトのリニューアルの例をご紹介します。 リニューアル前のサイトはそのアクセスをさばくため、静的なコンテンツを多用していましたが、サイト運営者の要望としては動的なコンテンツを導入したいとのことでした。 そのため、ハード・ソフトともに全面的な再設計を行いました。 その際には負荷対策が大きな課題となりました。 まず、Webサーバの負荷分散にはLinux Virtual Server(LVS)のロードバランサを利用しました。 オープンソースを利用することにより、 高価なロードバランサを使うことなく、複数台でのWebトラフィックの制御が可能となりました。 また、DBサーバについては、あえて分散構成は行いませんでした。 これはマルチマスタ構成にすることによって、アプリケーションが複雑化することを避けるためです。 そこで、64bit版Linuxと64bit版MySQLを使用し、シングルマスタ構成でも十分な性能が出せるようにしました。 とはいえ、アクセスのたびに直接DBにクエリを発行するのでは速度低下は避けられません。 とりわけセッション管理に関して問題となることが予想されました。 そのため、分散メモリキャッシュサーバmemcachedを利用し、セッション保持の確認には毎回DBにクエリを送らずとも済むようにいたしました。これにより、適切な時間内にレスポンスを返せるようにいたしました。 もっとも、会員規模やアクセスのばらつきにより、最適なアーキテクチャはサービスごとに異なります。 あまり大規模でないうちに大掛かりな構成を組んでしまうとサービスが軌道に乗る前から開発・運用コストがかさんでしまい、ユーザの要望の移り変わりに応えられなくなります。 一方で、スケーラビリティを意識しない構成でスタートしてしまうと、 ユーザ規模の拡大にアプリケーションが追従できなくなります。 ツインスパークでは、このような相反するご希望をそれぞれ考慮し、ご満足いただける提案をするよう心がけています。
2.開発手法
Webアプリケーション開発においては、その開発プロセスが重要となります。 パフォーマンスやセキュリティ、新機能追加を的確に行うには、先を見越した設計・実装が欠かせません。 しかしその一方で、あらゆることを想定したサービスは、最終的には不要な機能を作りこむことになり、コストが割高になってしまいます。 そこでは成長に合わせた設計と実装を迅速に行う必要があります。 このような開発を実現するため、ツインスパークでは「反復型開発」がよく行われています。 「反復型開発」とは、システムの設計と実装を繰り返しながら開発を行う開発スタイルです。 ある程度以上の規模のアプリケーションについては、最初に全ての設計を行わず、全体をいくつかの機能群に分割した後で、 そのうちの優先順位の高いものから開発を行います。 そしてその機能群をリリースしてから、次の機能群の開発を行います。 その結果、予定していたアプリケーション全体のリリースまでに、設計→実装の流れを何度か繰り返すことになります。 通常は、全体をいくつかの「フェーズ」に分割し、数週間から2ヶ月程度で１つのフェーズが終わるようなスケジューリングを行います。 適切な規模でフェーズ分割を行えば、スピーディにサービスを開始しながら、仕様を柔軟にコントロールできるようになります。
○実際の開発では
前述の開発においては、第1フェーズとして、まずベースとなる会員機能を核に、従来の掲示板サービスのリニューアルを行いました。 第1フェーズで開発した機能が公開された後、第2フェーズとして、ユーザからのフィードバックに基づく機能改良と、 また携帯向け機能の追加を行いました。 そして第3フェーズとして、新機能であるイラスト作成機能を追加しました。 それぞれのフェーズは、直前のフェーズで作成した機能を公開した後で、そのフィードバックも参考にしながら開発を行っています。 これにより、全体の開発が終わらなくとも、開発を行った機能をいち早くユーザに展開できます。 そのため、既に開発された機能の反応を見ながら、仕様の変更も含めて、 公開の優先順位をつけることができました。
3.運用
Webサービスを成功させるには、開発だけではなく、運用が重要です。 運用を見越したインフラの設計から、日々の障害検知とその対応まで、適切な品質とコストでの運用を行い続けることが、サービスそのものの 信頼に結びつきます。 インフラの設計においては、サービスの成長に合わせて必要十分なパフォーマンスを提供できるようにすることが 求められます。 初期であれば負荷への対処よりも迅速な機能追加が優先されていたとしても、アクセスが増えるにつれ、適切なスケーラビリティが必要とされます。 時にはインフラの再構成が行われることもあります。 再構成には、現状の稼働状況の分析調査から、 問題点の洗い出し、品質とコストのバランスのとれたソリューションの提案、そしてサービスへのインパクトを最小限にしつつ迅速な対応が求められます。 そのためには、単にハードウェア・ミドルウェアレベルの理解のみではなく、個別に開発されたアプリケーションレベルでの理解が欠かせません。 また、運用においては、自動化可能な部分は自動化によりコストを低減し、自動化困難な部分は有人による対応を行うというバランスが求められます。 そして、サーバ障害時にはサービスの復旧と原因調査、対策の提案と実行まで、迅速な対応が求められます。 ツインスパークでは、インフラの設計にあたっては、ネットワークエンジニアだけではなくアプリケーション開発者も交えて 可能な限りの問題点・懸念事項の洗い出しと予測を行い、適切なインフラの設計を行っています。 また運用時には、長年の運用経験と実績により、障害発生時にも、適切な一次対応・二次対応で、原因切り分けとその対応を行っています。
