読者です 読者をやめる 読者になる 読者になる

多趣味なやつの雑談

六本木で働くITエンジニアが内容を絞らずいろいろ書きます

IDCフロンティアのILBとコンテンツキャッシュ使ってみた

この記事はSpeee Advent Calendar 2016 - Qiitaの8日目の記事です。

前日の記事は
qiita.com
ディレクターなのに素晴らしい!

さて今回はクラウドの話をしようと思います。
昨今AWS Re:Inventで新たに発表された機能が気になりますが、たくさんのブログで紹介されているので国内クラウドについて書こうと思いました。
AWSGCP、Azureが目立ってますが私としては国内も頑張ってほしい〜

そこで国内クラウドとして利用しているクラウドとデータセンターのIDCフロンティアを事例紹介します。
IDCフロンティアのクラウドにはいくつかサービスが追加されましたが利用して良かったものを公式ドキュメントにない視点で見てみます。

ILB(ロードバランサー

公式:https://www.idcf.jp/cloud/ilb/
今まではIDCフロンティアクラウドでLBする場合は、仮想ルータのLB機能を利用していたと思います。その場合、LB自身がスケールすることがないため、アクセス上限がくることもあったでしょう。
またSSL証明書を設定できなかったため、SSLアクセサレーターがなくNginxなどで自前で作成しなければなりませんでした。

そこで登場したのがILBになります。詳しい仕様や価格などについては公式を見ていただいて、それ以外で感じたいい部分を記載します。
AWS-ELBのようなものですがまだまだ機能が足りません><がんばってください!!!

良い点

レイテンシー
SSLアクセサレーターとして利用したんですがNginxで用意した時よりレスポンス速度は向上しました。
f:id:eva-hashimoto:20161208134735p:plain
ガクッと減った日に切り替えたんですがこれは予想外にいい結果でした。まだ詳しくは見れてないですがSSLのハンドシェイク、鍵交換速度が向上したと思います。
まぁ元々のNginxの性能もあったでしょうけど自前で用意するよりずっといいです。

課題点

ルートドメインで利用できない
LBへの接続にはFQDNで指定するため、DNSにCNAME設定する必要があります。
多数のDNSサービスがありますが、ルートドメインの指定にAレコード以外を設定することがほぼできません。
IDCフロンティアにもDNSサービスがありますが上記の理由でルートドメインにILBを指すことができないのは残念でした。(2016年12月現在)
AWSの場合、Route53-ELBではルートドメインでもCNAME設定ができますがAWS以外のサービスでは指定できません><

モニタリング、分析
これも他のCDNと比べると弱さを感じました
AWS-CloudfrontではデバイスやHTTPステータスなど様々な情報を確認できますが、IDCフロンティア場合は主にトラフィック量とヒット率のみ確認ができます。

コンテンツキャッシュ(CDN)

公式:https://www.idcf.jp/cloud/cache/
シンプルなCDNなのでそこまで説明はいらないと思います。

良い点

レイテンシー
さすがYahoo!Japanを支えてるインフラですね。
国内配信であればCDNだけでも利用する価値はあるかもしれません。

課題点

キャッシュコントロール
CDNにデフォルト動作してほしいキャッシュ時間やヘッダー共通埋め込みなどがまだできません。
基本的にはOrginからくるヘッダーに依存しCache-Controlヘッダなどにより設定することは可能です。

共通課題

SSL証明書の一元管理ができていない
各サービスにSSL証明書の登録をしなければなりません。
ACMのようにしてほしい・・・

ログの出力がない
LBやCDNに用意されているモニタリング意外にも生ログの分析、調査というのは必要ですよね。
S3に自動でアップロードできたりすると素敵な気分になります。今ならAWS-Athenaがあるしね!

まとめ

課題と感じたところはほしい機能として感じることが多く、別の手法で解決が可能だったりします。
海外のクラウドサービスと比べるとまだまだ足りない部分はありますが国内クラウドサービスの中では先端を行ってるでしょう!国内DCベンダーのみ利用するしかないようなサービス、システムにはいい選択肢かと。

分散型NoSQLのAerospikeを触ってみようぜ!(導入編)

今回は Speee Advent Calendar 2015 - Qiita 22日目です。
昨日の記事はTei1988さんのPebble Watchでmrubyを試す(まだ動かせて無いよ編) - Qiitaでした。

Aerospikeとは?

前から気になってた分散型NoSQLのミドルウェアだったんですが有料版しかなかったので、なかなか試すことができない状態でした。しかし最近OSS化されたのでお手軽に試すことができるようになりました。
詳しい紹介はWEB+DB PRESS Vol.87|技術評論社で紹介されてます !

特徴としてはトランザクションを備えつつ高速な処理を実現しスケールが楽にできるらしい
ということでアド業界では注目されておりすでに導入している企業も多いようです
スマホ広告向けソリューションツール「F.O.X」、ミドルウェア「Aerospike」を採用し、広告効果測定におけるデータ基盤を強化 | CyberZ|スマートフォン広告マーケティング事業

今回の記事ではスループットのテストしませんので他のブログや自身で確認してください

インストール

Aerospikeはノードサーバと管理サーバ(amc)の2種がありますので個別で手順を載せます。

環境

VirtualBox
CentOS 6.7 x64(minimal)

  • 192.168.56.101 node1 + amc
  • 192.168.56.102 node2
  • 192.168.56.103 node3

必要なパッケージのインストール

[node1_amc]# yum install wget gcc python python-devel libffi-devel

AeroSpikeのnodeインストール

各Nodeサーバにインストールしましょう

[node1_amc]# wget -O aerospike.tgz 'http://aerospike.com/download/server/latest/artifact/el6'

[node1_amc]# tar -xvf aerospike.tgz

[node1_amc]# cd aerospike-server-community-3.7.0.2-el6

[node1_amc]# ./asinstall # will install the .rpm packages
クラスタ設定

設定ファイルはここに用意されてます
/etc/aerospike/aerospike.conf

クラスタは大きく分けてブロードキャストとメッシュ(Nodeを指定)の方法が用意されてますが、昨今のクラウドサービスではブロードキャスト通信ができないのでメッシュによる設定をやってみようと思います。
今回は3台あるのでnode1を軸にnode2,node3をクラスタにジョインさせる構築をしたいと思います。

node1 (192.168.56.101)

service {
	user root
	group root
	paxos-single-replica-limit 1
	pidfile /var/run/aerospike/asd.pid
	service-threads 4
	transaction-queues 4
	transaction-threads-per-queue 4
	proto-fd-max 15000
}

logging {
	file /var/log/aerospike/aerospike.log {
		context any info
	}
}

network {
	service {
		address 192.168.56.101
		port 3000
	}

	heartbeat {
		mode mesh
		port 3002
                address 192.168.56.101
		mesh-seed-address-port 192.168.56.101 3002 # 自身をメッシュの軸にする
		interval 250
		timeout 10
	}

	fabric {
		port 3001
	}
  
    info {
  		port 3003
  	}
  }

  namespace test {
  	replication-factor 2
  	memory-size 128M
  	default-ttl 30d
  	storage-engine memory
  }


Node2(192.168.56.102)

service {
	user root
	group root
	paxos-single-replica-limit 1
	pidfile /var/run/aerospike/asd.pid
	service-threads 4
	transaction-queues 4
	transaction-threads-per-queue 4
	proto-fd-max 15000
}

logging {
	file /var/log/aerospike/aerospike.log {
		context any info
	}
}

network {
	service {
		address 192.168.56.102
		port 3000
	}

	heartbeat {
		mode mesh
		port 3002
                address 192.168.56.102
		mesh-seed-address-port 192.168.56.101 3002
		interval 250
		timeout 10
	}

	fabric {
		port 3001
	}
  
    info {
  		port 3003
  	}
  }

  namespace test {
  	replication-factor 2
  	memory-size 128M
  	default-ttl 30d
  	storage-engine memory
  }


Node3(192.168.56.103)

service {
	user root
	group root
	paxos-single-replica-limit 1
	pidfile /var/run/aerospike/asd.pid
	service-threads 4
	transaction-queues 4
	transaction-threads-per-queue 4
	proto-fd-max 15000
}

logging {
	file /var/log/aerospike/aerospike.log {
		context any info
	}
}

network {
	service {
		address 192.168.56.103
		port 3000
	}

	heartbeat {
		mode mesh
		port 3002
                address 192.168.56.103
		mesh-seed-address-port 192.168.56.101 3002
		interval 250
		timeout 10
	}

	fabric {
		port 3001
	}
  
    info {
  		port 3003
  	}
  }

  namespace test {
  	replication-factor 2
  	memory-size 128M
  	default-ttl 30d
  	storage-engine memory
  }

起動は後ほど!!

管理サーバ(AMC)のインストール

aerospikeが標準で用意している管理ソフトウェアの見た目(だけではない)がいいのでそれもインストールしたいと思います。
基本的には本家のインストール手順をやればいいです
Install on Red Hat and Centos | Aerospike Management Console Manual | Aerospike

pipのインストール
[node1_amc]# wget https://bootstrap.pypa.io/get-pip.py
[node1_amc]# python get-pip.py

[node1_amc]# pip install markupsafe
[node1_amc]# pip install paramiko
[node1_amc]# pip install ecdsa
[node1_amc]# pip install pycrypto
[node1_amc]# pip install bcrypt
AMCのインストール

本家サイトからダウンロードCommunity版をダウンロード
執筆時点では3.6.4でした

[node1_amc]# rpm -ivh aerospike-amc-community-3.6.4-el5.x86_64.rpm
・・・・・
You may check greenlet compilation output in /tmp/greenlet.log and delete it if all is OK
building setproctitle...
You may check setproctitle compilation output in /tmp/setproctitle.log and delete it if all is OK
Copied /opt/amc/config/ to /etc/amc/
Successfully installed AMC.

まずは管理サーバを起動させます

[node1_amc]# service amc start

Webインターフェースが用意されてるのでアクセスしてみましょう!
http://192.168.56.101:8081/
f:id:eva-hashimoto:20151222164254p:plain
どのクラスタを見たいのか?というダイアログが初期ではでます。
今回の場合は192.168.56.101(localhost)ですが入力してもノードが立ち上がってないのでエラーになります。

ノードを立ち上げてみましょう

まずはNode1のみを立ち上げてみる

[node1_amc]# service aerospike start

今度はクラスタを指定すると管理画面が表示されます。
かっこいい〜
f:id:eva-hashimoto:20151222165156p:plain

引き続きnode2を立ち上げて管理画面を見てみるとジョインしたことがわかります。
ノードが追加されるまでは10秒くらいかかってそうです。
この時にデータが入っている状態でシャーディングなど起きたらもっと時間がかかると思いますが、今回は試しませんw
f:id:eva-hashimoto:20151222165503p:plain

最後にNode3を立ち上げてみる
f:id:eva-hashimoto:20151222165907p:plain
無事3台によるクラスタ構築がおわりました。

namespaceの領域を増やしてみる

aerospikeはDBでいうところのスキーマみたいにnamespaceによる管理ができます。
namespace毎に各ノードのメモリ量など設定ファイルに記載できますので
サーバスペックが違った場合でも増減管理がやりやすい特徴があると思います。
今回のノードにはtestというnamespaceで128MBの領域を用意しました。
f:id:eva-hashimoto:20151222170143p:plain

ではnode2だけ領域を増やしてみたいと思います。

namespace test {
  	replication-factor 2
  	memory-size 256M  # 128M -> 256MB
  	default-ttl 30d
  	storage-engine memory
  }

再起動してみる

[node2]# service aerospike restart

すぐに落ちたことを認識しました
f:id:eva-hashimoto:20151222170526p:plain

そしてnode2が再度認識されたらちゃんとnamespace内のメモリ量も増えてました!
f:id:eva-hashimoto:20151222170645p:plain
今回は仕様についての確認は行いませんが後ほどフェールバックの動きやシャーディング動作を検証してみたいと思います。
実運用や各サービス特性にマッチしていれば採用できるポテンシャルは十分にありそうです。(まだテストしてないけどw)

さて次はデータ入れて検証遊んでみようと思います。

高トラフィックを想定したデータ層の話

初めまして!六本木で働くITエンジニアです

この記事は、Speee Advent Calendarの16日目です。

※遅れてすみません!!!!

qiita.com

 

初エントリーの記事としては高トラフィックのデータベース設計についてというお題だけど中身としては「データの鮮度」について語っていこうと思う

※テーブル設計とかそういうのは今回はでないので期待はずれの方はそっ閉じしてください 

データの鮮度とは?

あまり聞きなれない表現かもしれないですが、BI業界なんかでは調査・分析するデータについて「精度」と「鮮度」という言葉で表現されることがあります。

  • 精度:調査として適切な整合性がとれたデータになっているか?
  • 鮮度:いつのデータか?いつ使うデータか?

私はWebアプリケーションのアーキテクチャとしてModel層を設計するに当たって、

構成するデータの鮮度を基準としてミドルウェアを選定しています。

f:id:eva-hashimoto:20151217112115p:plain生で食べたいなら刺身だし保存するなら干物に加工して食べますよね!

Webアプリケーションのデータも同じ感覚なんですけど、いつ使うか?や更新・参照頻度、データサイズなどによって加工(ミドルウェアの違い)を行うことが重要です

様々なデータ

このはてブ自体を構成するページもいろんなデータがあると思います。

 などなど多様なデータで構成されてますよね

これらをRDBで一括管理するならアプリケーション構築もインフラの運用や学習コストも楽でしょう。しかし、そのままではトラフィックが増えたりデータサイズが増えることで様々な問題が起きることは周知の事実ですよね。

では初めからある程度のアーキテクチャ設計が必要だよね!?ってのが私の思想です

それだと初期開発の工数ガーって話は後ほど

調理法を見極める

まずは各データの性質を見ていく必要がある

※前提となる性質は個人的な仮説でありはてブの仕様ではないです

ブログ記事
  • 基本的には更新がほぼなく参照されるばかり
  • サイトを構成する上で一番大事なデータ
  • 記事はどんどん増えていく
テンプレート
  • 更新はほぼなく参照ばかり
  • データ量は1アカウントに1個のデータ
ユーザデータ
  • 外部要因(お気に入りなど)による更新が多くデータとの連携が必要
アクセスログ
  • 大量のアクセス数によるデータの蓄積と集計が必要
  • ページ上には更新タイムラグがあっても問題がない

調理法の選択

細かいデータベース層のミドルウェアの説明は省きます

RDBMySQL, Oracle, PostgreSQLなど)

トランザクションがあるのでデータの整合性はばっちりですよね。

各テーブルのJOINなど多様なデータの取得方法が可能でありSQLはやっぱり強力です。

しかしスケーラビリティの向上には工夫が必要でレプリケーションやパーティショニングを駆使する必要が出てきて結局アプリに手を加えるケースが出てきやすい

例:ユーザに関するデータ、記事のステータスとか

 

KVS、NoSQL(redis, MongoDB, Cassandraなど)

RDB以外ということで強引にまとめましたw

CAP定理をどれだけ満たしているか、データの検索方法によって各ミドルウェアで違うのでそれによって選択すべきだと思います。

例:記事のデータはMongoDB、PVのカウントはredis

MongoDBはレプリカセットによって可用性や耐障害性を向上しやすくクライアントによって参照先の制御ができるため、参照するデータが一意であり重要なデータの場合はベターな選択だと思います。また、ドキュメント指向なので記事の修正などによるデータの変更も柔軟に行える特徴にもマッチしている。

redisは多彩なデータセット(ソート済みやハッシュ)と一貫性のある処理をオンメモリで高速に行うことが特徴としてあげられるのでPVのカウントなどに適しているかと

 

簡単な例ではありましたが各ミドルウェアの特性とデータの特性を合わせることでミドルウェアを最大限のパフォーマンスを引き出せると考えています。

別にトラフィックやデータ数が少ないならRDB一本で問題ないですw

 

データ層で詰まらせない

データ層が詰まってしまったらいくらWebサーバをオートスケールしても意味がありません。またデータ層がオートスケールするにはアプリケーション側の工夫が必要なケースが多いため、改修工数が多くなることがあると思います。

弊社のサービスには立ち上げてから2年かからず大きくトラフィックを伸ばしたサービスがありますがデータ層で詰まったことは1度もありませんでした。

※Webサーバで詰まったことは何度か・・・

その為、開発に集中できサービス成長が早かったのかなと

データ層の設計次第で数年間のサービス開発のあり方が変わると経験上で覚えているので初期設計、実装のコストはトータルでは安いと思う

 

下記は実際に弊社サービスのモニタリング結果です

ね、DB系のサーバの負荷低いでしょ?

f:id:eva-hashimoto:20151217142232p:plain

※諸事情によりサービス名などは公開できません。

 

データの持たせ方一つでインフラのコストも開発のコストも大きく変わると思います。

アプリケーションの作りやすさや学習コストとトレードオフになるところもありますが

サービスが成長することを、初めから意識することがビジネスにもエンジニアの技術力にも向上のきっかけになるのではないでしょうか。

サービスが失敗するかもしれないから「とりあえず」の仕様なんかで作りたくないし妥協なんかしたくないです。

 

それでは!