 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| OSS＋アウトソースの活用 | ||||||||||
|
開発にあたっては、設計は日本で行い、実装はフィリピンの協力会社で行うという体制をとった。 フィリピンはアジア圏の中でもっとも英語が使われており、通常のビジネス会話も英語がメインになっている。そのため、様々な国のコミュニティから、まだ日本語化されていない最新情報をダイレクトに集めることを可能だ。 また、OSSではないアプリケーションは、コスト高である以外にも、公開されていないブラックボックスの部分があり、ベンダーに確認をしなければならないケースが多々ある。これは、開発速度に影響をおよぼすだけではなく、改変が認められないこともある。 「開発コストの低減」「情報の鮮度・量」「実績・ノウハウ」という点を重視するにあたって、OSS＋アウトソースは大きな影響をあたえた。 |
||||||||||
| OSSの情報量と導入速度 | ||||||||||
|
冒頭でも述べたようにアーティストファンサイトでは、イベント時にアクセスが集中し、一時的に負荷が膨れ上がることがある。しかし、イベント時にサービスが停止してしまっては大きなクレームとなる。 そこで、まずはスケールアップで対応することを考えた。しかし、同時アクセスにどれだけ耐えられるのか、データベースの書き込み速度に耐えられるのかといった不安があった。そんな折、ロードバランサが提供されることになり、再び論議をした。 ロードバランスを活用することで、サーバの役割をWeb／データベース／ファイルと分け、サーバの負荷をさらに軽減することができるということもあり、スケールアップではなくスケールアウトの目的でロードバランサの採用を決めた。 そうして、スペックの増強ではなくロードバランサによってWebサーバの負荷を分散することになった。 しかし、そのロードバランサの性能が未知数であるうえ、サーバを5台設置してOSやアプリケーションの実装などの作業を行いながらであったため、十分に検証する時間はなかった。 ロードバランサを利用する時の一番問題はセッションの維持・共有である。その方法は各々で異なり、アプリケーション側の対応も必要となるからだ。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
