前回記事はこちら

データベースサーバ、バッチサーバを順に整理してきましたが、いよいよウェブサーバです。

4. ウェブサーバ

ウェブサーバは3台になるので、いろいろとやることがあります。

DNSラウンドロビンでアクセスをバランシング

これまでkaupon.jpへのユーザアクセスは1台で受けていたので、DNSの設定も単純でしたが、今回から3台に振り分ける必要が出てきます。
バランサ機器の導入や、Apacheのバランシングモジュールを入れるのも手ですが、手軽さを重視してDNSラウンドロビンを利用することにします。

DNSラウンドロビンは、簡単に言えばひとつのドメインに3つのIPアドレスを割り振ることで、アクセスをランダムに3台に振り分けます。
手軽ではありますが、重み付けや障害時の対応等が十分ではない仕組みのため、将来的には別のやり方にしたいところです。

概略ですが、以下の紹介記事など参考になります（※利用のDNSサーバによって設定変わります）。

ラウンドロビンDNSの設定

この手法でやる場合、Apacheの設定についてはこれまで通りで済みます。
アプリケーション側についても、同じファイル群を各サーバに配置すればOKです。

lsyncdでアップされた画像を同期

次にユーザアクションによって、更新される情報の同期です。

DBにある情報、セッションデータについては1つのDBサーバに集約していますので、同期を意識する必要はありませんが、面倒なのが画像などのデータです。

ユーザがアイコン画像などをアップした際、単純にこれまで通り受け取ったウェブサーバのローカル上に配置しても、残り2台のウェブサーバには反映されません。
これは問題があります。

対応として、画像のアップ先を1台に集約する手もありますが、アプリケーションにも改修が入るのと、画像アップ用に小さな仕組みをつくる必要が出てきます。
手軽にやるのであれば、lsyncdというサーバがファイルの更新を検知すると同時にrsyncにより別サーバに瞬時に配布をおこなう仕組みがあります。

lsyncdをつかって簡単にファイル同期を

rsyncはアプリケーションデータの複数台配布やログバックアップなどにも活躍する、ファイル差分を見て同期してくれる仕組みです。

rsync

この手法は、当時ロケスタのwadapさんに教わりました。
KAUPONでは当初サーバ間でNFSマウントによりファイルを共有しようとして、ウェブサーバのロード値が一瞬で100を超えた苦い思い出があります。
NFSマウントは参照の度にマウント先のサーバを見にいくことになるので、性能のよいサーバや速度のでるネットワークがないと機能しないものでした。

その点、lsyncdは必要なファイルを差分のみサーバ間で受け渡すので、
更新時に数秒のタイムラグはでるものの、参照はローカルなので1台運用の時と変わらないパフォーマンスが出せます。

lsyncdは相互のデータ更新はできないので、以下のような流れでデータを受け渡すようにしました。

ウェブサーバとバッチサーバにlsyncdをインストールし、設定をおこないます。

KAUPONでは、ユーザのアップする画像以外にも裏側で更新する静的なHTMLや、案件の入稿画像などにも同様の仕組みを用いて、サーバ間のファイル共有を実現しています。

まとめ

ざーっと整理してみましたが、いかがだったでしょうか。

さまざまなやり方がある中で、利用している環境や規模に合わせた増設をおこなうのは、アプリエンジニア出身の身としてはまだまだ難易度が高い部分ではあります。

事業予測とパフォーマンス予測を掛けあわせて、適切な増設計画を立てられればベストですが、なかなか計画通りに進まないのも現実です。
今回は省略していますが、監視やパフォーマンスレポーティングの仕組みをうまく構築して、逐一サーバの状況を見ながら一歩先の増設計画を考えていくという作業が求められると思っています。

締めになりますが、以下のインフラ本は参考にさせてもらっています。
内容が具体的でわかりやすく、MySQL設定項目などの詳細ものっているのでオススメです。

今回はこのあたりで！

引き続き採用強化中です！

日々試行錯誤しながら、KAUPON開発メンバーは頑張ってます！
KAUPONのインフラをもっとイケてる仕組みに変えたいという方、アプリ開発をがっつりやりたいという方、どちらの興味も歓迎ですので気になった方は以下もチェックしてみてください。

個人の趣味的サービスにしても、ベンチャーが始めたサービスにしても、ユーザが増えてきたときに必ず直面するのがサーバ増設です。

1台のサーバでアクセスがさばききれなくなったとき、いずれは複数台化するタイミングがきます（きました）。

近年、VPS、クラウドなど、即時で立ち上げられるサービスも数多く出ていて、選択肢は広がっています。
VPSであれば専用サーバよりも安く手軽に立ち上げられるし、クラウドであればコストを抑えながら日々変わるアクセス負荷に応じて、柔軟にサーバ増設や集約が可能なメリットがあります。

目的やコストに応じた選択が必要ですが、やり方はどうあれ、最初の増設は少々厄介です。
当たり前と言われればそれまでですが、1台のサーバを2台にするのであれば、ユーザにはどちらのサーバでも同じコンテンツを見せる必要があります。

今回はそのあたりに軸をおいて、サービスのサーバ増設について整理してみました。

昨年末ごろに当時KAUPONで発生していたサーバダウンや処理遅延などの根本対策として、実際におこなった事例をベースにしています。
最新のベストプラクティスではないかもしれませんが、いちサービスでの事例として参考になれば幸いです。

環境について

KAUPONはいわゆるLAMP環境です。

• Linux（CentOS）
• Apache
• MySQL
• PHP

多少詳しい環境についてはこちらの記事をご覧ください。

KAUPONつくってます
KAUPON開発で使ったオープンソース10個

1. 分割単位を検討する

増設にあたり、単純に同じシゴトをするサーバを増やすこともできますが、基本的には役割を分けて増設するやり方がスタンダードだと思います。

コンテンツを返すサーバはいっぱい必要だけど、データベース用のサーバは1個でいいよね、とかそういう話です。

役割を分けるために、どのようなシゴトがあるかを考えます。
細かいモジュールまで見ていくとキリがありませんので、大きなシゴトのみ整理します。

• アプリケーション（PHP）
• バッチ（PHP）
• ウェブサーバ（Apache）
• データベース（MySQL）
• データキャッシュ（memcached）
• メール送信（Postfix）

大きくはこんなところでしょうか。

これを元に、増設後のサーバ構成を検討してみます。

ウェブサーバ

• アプリケーション（PHP）
• ウェブサーバ（Apache）
• メール送信（Postfix）

バッチサーバ

• バッチ（PHP）
• メール送信（Postfix）

データベースサーバ

• データベース（MySQL）
• データキャッシュ（memcached）

今回、メール送信機能はDBサーバを除く各サーバに持たせることにしています。
セッションデータや頻繁に参照されるデータをつっこむmemcachedはできれば別サーバにしたいところですが、コスト面を考慮してDBサーバに相乗りする形にしています。

ウェブサーバはアクセスを集中的に受けるため台数を調整して、以下の構成でサーバ増設を進めていくことにします。

before

• サーバ×1

after

• ウェブサーバ×3
• バッチサーバ×1
• データベースサーバ×1

2. データベースサーバ

まずはデータベースサーバです。

データベースサーバを分けることにより、大量アクセスなどでCPU使用率やメモリ使用率があがった場合でも、MySQLやmemcachedに処理影響を与えにくい構成がとれるようになります。

MySQLはソケット通信からポート通信に

これまではサーバ内のDBを見ていましたが、今回から別のサーバのDBを見ることになるので、ソケット通信からポート通信に変わります。
セキュリティを考慮して、標準ポートの変更、サーバのポート開放、ユーザアクセス権限をおこなっておきます。

ユーザアクセス権限については、ホスト単位でのアクセス制限などをおこないます。

具体的なSQL例などは以下のサイトにお世話になってます。

MySQL講座 [Smart]

よくはまるのでTIPSとして。
権限変更時は反映のためのFLUSH文の実行を忘れずに。これが原因で権限反映できてないことに気づくと悲しくなります。

FLUSH PRIVILEGES;

アプリケーション側については、設定を切り替えるだけでよく、cakePHPであればapp/config/database.phpを編集して、ソケットファイルしてからポート番号指定に切り替えればOKです。

memcachedはそのまま利用

memcachedは、ローカルホストの接続でもポートを使用して通信していますので利用方法は基本的には変わらずです。
MySQL同様、セキュリティを考慮し、標準ポートの変更、サーバのポート開放をおこないます。

3. バッチサーバ

次はバッチサーバです。

バッチサーバを分けることにより、集計処理やメルマガ送信時のバッチ処理などによりCPU使用率やメモリ使用率があがった場合でも、ユーザレスポンスに影響が及ばなくなります。
今回はバッチサーバを1台としていますが、将来的な複数台化や処理時間が増加した際に同サーバ内での並列実行ができるように、それぞれのバッチを分割実行できる形にしておけると楽だと思います。

バッチ処理をグループ化して実行しやすく

KAUPONでは、例えばこんな感じでバッチ処理を引数でグループ化して、分割実行ができる形にしています。

/hogehoge/shell_exec.sh daily_magazine 1
/hogehoge/shell_exec.sh daily_magazine 2
/hogehoge/shell_exec.sh daily_magazine 3
/hogehoge/shell_exec.sh daily_magazine 4
/hogehoge/shell_exec.sh daily_magazine 5

グループ化にはIDをグループ数で割った余りをよく使います。

ユーザIDならユーザID%5+1とかすれば、日々IDが増えても均等に1～5のグループをつくることができます。

今回はこのあたりで。次回は増設の肝となるウェブサーバを整理します。

引き続き採用強化中です！

日々試行錯誤しながら、KAUPON開発メンバーは頑張ってます！
KAUPONのインフラをもっとイケてる仕組みに変えたいという方、アプリ開発をがっつりやりたいという方、どちらの興味も歓迎ですので気になった方は以下もチェックしてみてください。

また、デザイナーについても募集中ですのでご興味ある方はぜひ！
ソーシャルコマースサイト「KAUPON」のWebデザイナー

個人的にはキラメックスの社長のブログというものでたまに思ったこととか書いたりしてるんですが、こちらでは技術話やクリエィティブに関することを書いていって、誰かの役に立つといいなぁと思ってます。

さて第1回目の投稿ですが、「KAUPON開発で使ったオープンソース10個」というタイトルですが、KAUPONは2010年5月にローンチしてまして、当時キラメックスはまだ僕だけでお金もなく、学生のR君に一部手伝ってもらいながらもほぼ一人でシステムからプログラムにデザインと全部やる必要があったので、とにかくお金を掛けずに効率良くやることを心がけていました。格好良く言うとそうですが、まぁそうしないとビジネスとして成り立たたない状況でした。

そんな中、カウポンを作って行く上で陰の英雄とも言えるOSS（オープンソース）にはとてもお世話になりましてので、ここで感謝の気持ちも込めて、ローンチ当時利用していたOSSを紹介させていただこうと思います！

システム編

Linux (CentOS)

Redhat系の方が個人的に慣れていて好きなので使っています。ありがとうございます。

Apache

言わずと知れた世界中でもっとも使われているWebサーバソフトウェア。ありがとうございます。

MySQL

こちらも言わずと知れた世界中でもっとも使われているオープンソースデータベース。ありがとうございます。

Postfix

使いやすいMTA。リリース当初はSendmail使ってたんですが、そっこうで重くなって落ちて焦ってPostfixに変更したのは今では良い思い出。ありがとうございます。

プログラム編

PHP

全てPHPで書いてます。利用者が多く、色々とドキュメントやソースが落ちていて独学でも勉強しやすいので僕にはピッタリ。ありがとうございます。

CakePHP

PHP用の高速開発フレームワーク。非常に高速に効率良く開発できて便利。普通に使うと重いですが色々とイジれば問題無し。ありがとうございます。

デザイン編

jQuery

JavaScriptライブラリ。実装しやすく軽くて便利。これだけでちょっとリッチなサイトにできます。ありがとうございます。

FAMFAMFAM icon

オープンソースではないですがMark Jamesさんのフリーアイコン集。種類が豊富でデザインもGoodなので多様させていただきました。いろんなサイトで見ますよね。ありがとうございます。

番外編

Subversion

バージョン管理システム。ミスってもすぐ戻せるので安心開発。ありがとうございます。

Redmine

プロジェクト管理ソフトウェア。忘れないようにタスク管理したり、進捗管理したり。ありがとうございます。

以上がKAUPONローンチ当初利用していたOSS10個です。今でも使っているものが多数ですが、開始当初よりシステムの規模も大きくなり、それに合わせて変更や追加したものも多くなっています。そういうものはまた違うメンバーから紹介があるかもしれませんね。

このようにOSSを使うことでスタートアップでもお金を掛けずに素早くサービスが開発できます。ただそれにはOSSを作っている人たちの努力があるから、ということを忘れないようにしたいものです。これらがなければKAUPONは作れなかった！

最後に

上記のようなOSSを駆使しながら新しい価値を創るべく、KAUPON開発メンバーは日々頑張ってます！もしご興味があれば是非JOINしてほしいなぁと思っていますので、お気軽にご応募ください！

初めての投稿になりますが、今回は「CSSの指定方法、こうやれば使いやすいんじゃ？」というテーマで（短めに）お送りします。

例えば新たなWEBサイトのコーディングで、.main-boxというクラスを作るとします。

.main-box {
	float: left;
	width: 500px;
	border: solid 1px #ccc;
	background: #eee;
	margin: 0 0 20px 0;
	padding: 9px;
}

ちょっと寂しいですね、CSS3を使って装飾してみましょう

.main-box {
	float: left;
	width: 500px;
	border: solid 1px #ccc;
	background: #eee;
	margin: 0 0 20px 0;
	padding: 9px;
	border-radius: 5px;
	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;
	box-shadow: 0px 2px 3px #ddd;
	-webkit-box-shadow: 0px 2px 3px #ddd;
	-moz-box-shadow: 0px 2px 3px #ddd;
}

それっぽい感じになりました。その後コーディングを進めていくうちに、.sub-boxが必要になりました。

.sub-box {
	float: right;
	width: 250px;
	background: #eee;
	margin: 0 0 20px 0;
	padding: 10px;
}

これもちょっと寂しいですね、デザインを統一したいので.main-boxに合わせてみましょう

.sub-box {
	float: right;
	width: 250px;
	background: #eee;
	margin: 0 0 20px 0;
	padding: 10px;
	border-radius: 5px;
	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;
	box-shadow: 0px 2px 3px #ddd;
	-webkit-box-shadow: 0px 2px 3px #ddd;
	-moz-box-shadow: 0px 2px 3px #ddd;
}

それっぽい感じになりました。

…て進めていくと、何回も同じプロパティを書く事になってファイルサイズも大きくなるし面倒ですよね。なので、class名をプロパティのまとまり的に切ってみました。

.main-box {
	width: 500px;
	border: solid 1px #ccc;
	background: #eee;
	margin: 0 0 20px 0;
	padding: 9px;
}
.sub-box {
	width: 250px;
	background: #eee;
	margin: 0 0 20px 0;
	padding: 10px;
}
.leftcol {
	float: left;
}
.rightcol {
	float: right;
}
.radius5 {
	border-radius: 5px;
	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;
}
.shadow3 {
	box-shadow: 0px 2px 3px #ddd;
	-webkit-box-shadow: 0px 2px 3px #ddd;
	-moz-box-shadow: 0px 2px 3px #ddd;
}

こんな感じでどうでしょうか。HTMLは

<div class="wrapper clearfix">
	<div class="main-box leftcol radius5 shadow3">
		some contents…
	</div>
	<div class="sub-box rightcol radius5 shadow3">
		some contents...
	</div>
</div>

的な感じでマークアップすれば良いですね。さらに分解してみます。

.border-box {
	border: solid 1px #ccc;
	background: #eee;
	margin: 0 0 20px 0;
	padding: 9px;
}
.plain-box {
	background: #eee;
	margin: 0 0 20px 0;
	padding: 10px;
}
.unit-500 {
	width: 500px;
}
.unit-250 {
	width: 250px;
}
.leftcol {
	float: left;
}
.rightcol {
	float: right;
}
.radius5 {
	border-radius: 5px;
	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;
}
.shadow3 {
	box-shadow: 0px 2px 3px #ddd;
	-webkit-box-shadow: 0px 2px 3px #ddd;
	-moz-box-shadow: 0px 2px 3px #ddd;
}

どうでしょうか。HTMLは

<div class="wrapper clearfix">
	<div class="border-box unit-500 leftcol radius5 shadow3">
		some contents…
	</div>
	<div class="plain-box unit-250 rightcol radius5 shadow3">
		some contents...
	</div>
</div>

的な感じに。さらに

<div class="wrapper clearfix">
	<div class="unit-500 leftcol">
		<div class="border-box radius5 shadow3">
			some contents…
		</div>
		<div class="plain-box radius5 shadow3">
			some contents…
		</div>
	</div>
	<div class="unit-250 rightcol">
		<div class="plain-box radius5 shadow3">
			some contents...
		</div>
		<div class="border-box radius5 shadow3">
			some contents…
		</div>
		<div class="plain-box">
			some contents...
		</div>
	</div>
</div>

やり過ぎかもしれませんがこんな感じで書いてくことが出来ますね。この「unit-500, unit-250」部分をCSSグリッドフレームワークと組み合わせたりすれば、より使い易くなりそうです。

あとは例えば、.search-boxとか先に作った後で「あー他のページで同じデザインの部分あったのにsearchとか名前付けちゃったから使い回し出来ない！」的な事もなくなりそうですね。

今回は以上です。では！

最初の投稿ということで、ゆるーいお話からさせていただこうかと思っています。

今回のブログのテーマは「コーディング規約」です。
#前回の田中の投稿で、バッチエース(バッチを書くのが好きなだけです)とか言われたので、バッチについて書こうかとも思いましたが、それはまたそのうち。すんません。

プログラミング言語には、コーディング規約と呼ばれるものが存在します。基本的なコーディングスタイルや、命名規則についてまとめられた、コーディング時の決め事です。
誤解を恐れずに言えば、コーディング時のちょっとした基準になる程度のものなので、そんなに強制力を持つようなものではありません。
ただ、コーディング規約を知らないまま実装を進めてしまうと、とある問題が発生します。

それは、書く人によって、

違う言語で実装してるんじゃないか？

と思うくらいに、別物に見えるソースコードになってしまう可能性があるということです。
その結果、可読性が低下し、保守性が低下します。特に、現在のPHPのような、記述方法に強い強制力が無い言語では、それが顕著に表れます。

もちろんシステムとして稼働はしているのですが、動けばいいは、あまり美しいとは言えませんよね。
上位のアーキテクトがきちんとしていれば、きっと誰が書いても同じようなソースコードになるはずです。そして、それが理想だと思っています。

例えば、一つ一つのコントローラーやバッチが、それぞれまったく違う記法で記述されていたら、なんとなく気持ち悪いじゃないですか。
いや、動くんですけどね。動くんですけど。動いてるんですけど。

ネジの色が一本一本違っていたら、気持ち悪いじゃないですか。そんなことないですか？

陶芸家は、
ご飯食べれれば何でもいいだろ

なんて言って茶碗を作るようなことはしないですよね【謎】

ということで、「コーディング規約を守る」ということを、強く勧めたいのです。
KAUPONでは主にPHPを使用しているので、PHPを例にお話してみますかね。

たとえば、Pythonのソースコードは（えっ？）

def hoge(x):
    if x == 0:
        return 1
    else:
        return 0

↑こんな感じです。

たとえば、Haskellのソースコードは（えっ？）

main = do s <- getContents
          putStr s

↑こんな感じです。

上記の両方の言語に共通するコーディング規約があります。それはぼくの大好きなコーディング規約の一つで、「ブロック構造をインデントによって記述する」というものです。
一見普通に見えるソースコードですが、上記のどちらも、if文やdo記法のインデントが少しでも違っていたら動作しません。これによって、自然と、誰が書いても同じような雰囲気を持つソースコードになります。

では、PHPはどうでしょう。

public function hoge($x)
{
    if ($x == 0) {
        return true;
    } else {
        return false;
    }
}

↑これは正常に動きます。

function hoge($x) {
    if ($x == 0) return true;
    return false;
}

↑これも正常に動きます。

public function hoge($x)
{
   if ($x == 0) {
   return true;
     }
   else {
   return false;
   }
}

↑これも正常に動きます。

おかしいだろ

そこで、コーディング規約の登場です。
PHPでは主にPEARのコーディング規約が使われます。Zendの規約もありますが、PEARコーディング規約の方が使用されるケースが多いかと思います。

コーディング規約を守ることで、複数人での実装時も、ソースコードに統一性が出ます。それによって、可読性や保守性が上がります。ソースコードの品質が上がるのです。

必ずしもPEARのコーディング規約に従わなければいけないというわけでもありません。プロジェクト内で独自のコーディング規約を設定するというのも良いかと思います。
問題はあくまでも、実装に関するアーキテクトがきちんとしていないということです。

PHPは本当に様々な書き方ができます。それはメリットでもあり、デメリットでもあります。エンジニアをそのまま映す鏡とでも言っておきましょうか。（別にうまくねぇ）

ほんの少しだけ時間を取って、もう一度コーディング規約を読んでみませんか？新しい発見があるかもしれませんし。

「switch文のdefault句で何も処理をしない場合は、あえて何も処理をしていない旨をコメントに残す。」
とかね。

まじなんだよそれそんなの知らねぇよ。
と思ったアナタ！コーディング規約を熟読しましょう。

そんなの知ってるよ。普通のこと言ってんじゃねぇよ。
と思ったアナタ！偉そうなことを言ってしまい、大変申し訳ございませんでした。次回はもう少しがんばります。

PythonやHaskellのようにコーディング規約を守らないと、動作しないような言語であれば、誰が書いてもある程度は似たようなソースコードになります。だからPythonが好きだっていう人もいますしね（ぼくも）。

でも、PHPだってアーキテクトさえきちんとすれば、誰が書いても似たようなソースコードになるはずなんです。良いソースコードが書けるはずなんです。

PHPだったら、エラーレベルでE_STRICTを設定しておけば、PHP5の記述方法に準拠していない場合は、注意してくれます。これも良いかと思います。ある程度ソースコードに統一性が出ますので。

いろんな人が参加するプロジェクトで、
いくつもバッチがあって、
それぞれ別の人が作っていて、
それぞれがぜんぜん違うソースコード。
ちょっと嫌じゃないですか？

もちろん冒頭でも述べた通り、コーディング規約にそこまでの強制力はありません。あくまでも、実装に対するアーキテクトの参考の一つです。
まぁエンジニアであれば、人それぞれにこだわりはあると思いますし、このコーディング規約はどうなの？って思う規約もあるでしょうし、その辺りのアレ【謎】は、うまいことやってもらえれば。

なんていうか、やっぱり、ソースコード見て、エレガントだねって言われたいじゃないですか。

と、そんな感じで今回は終わりにしたいと思います。
次回はビッキビキデザイナー兼マークアップエンジニアのけんと氏です。

では、また。

今日から、キラメックスでサービスをつくってる人たちのブログがスタートしました。

技術/デザインネタなどを中心に社内の開発メンバー持ち回りでゆるく更新していきますので、どうぞよろしくお願いします。

初めての記事ということで、今回はKAUPONで使っている技術の話をざっくりしたいと思います。

言語はPHPを使っています。

PHPは型の扱いやエラー処理などがJavaなどと比べるとゆるめな言語ではありますが、その分柔軟で書きやすく、ネット上のドキュメントも豊富なため、とくに小さくサービスを立ち上げるには適した言語だと思っています。

PHPを扱えるエンジニアが世の中に多いのも魅力です。

フレームワークはCakePHPを使っています。

フロントだけでなく、バッチでもしっかりと利用することができるので、かなり重宝しています。
RubyのRailsを元にしているだけあって、記述ルールさえ守れば設定で悩まされることもなく、また自分たちで拡張もしやすいフレームワークです。

KAUPONの場合も、PC版、モバイル版、バッチその他で使い回したいモデルやライブラリ群を共通化するために構成を一部独自化して対応しています。

cakeは重い！という話も耳にしますが、ページキャッシュを利用したり、アクセスの多いページはcakeを通さないなど、独自の仕組みもかけ合わせることでパフォーマンスを担保しています。

フレームワークを使うと開発生産性が高い分、パフォーマンスが落ちてしまうのは仕方がないことなので、生産性とパフォーマンスを天秤にかけながら、必要なところにはちょっとだけ手を入れています。

データベースはMySQLを使っています。

マスタ・スレーブの構成をとっていますが、現在はスレーブは分析用途としてサービスからは切り離した形で使っています。

DBアクセスを減らすために、フレームワーク側で参照データをmemcachedに格納させて使いまわしたり、参照条件は単純だけれどもアクセスが頻繁で大量なデータについてはCassandraにも持たせたりすることでDBに負荷が集中しない仕組みをつくっています。

特にマイフレンド機能や、買った人の顔を表示する機能の部分では、Cassandraが大活躍してくれています。

現在はKAUPONや管理ツールなどを含め、専用ネットワーク＋専用サーバ数台で運用をしています。

トレンドから言えば、クラウド利用や仮想化サーバをもっと活用する手もあると思いますが、アプリ出身者中心でエンジニア人数も限られた状況で、あまり多くのサーバを運用するのは得策ではないという判断から、現在は専用サーバで安定した運用体制をとっています。

とはいえ、身軽さがベンチャーのうりでもあるので、状況やトレンドに応じて利用する技術やインフラ構成の見直しはしていきたいと考えています。

だいぶざっくりとKAUPONで使っている技術の話をさせてもらいましたが、いかがだったでしょうか。

今後もう少し掘り下げた話や、具体的なサービス運用にまつわる話を書いていければと思いますので、よろしくお願いします。

次回はキラメックスのバッチエース、ふみやが登場します。