多趣味なやつの雑談

大手町で働くVPoE兼PMが内容を絞らずいろいろ書きます

手段は単なるHOWに過ぎない

今回のキーワード
・銀の弾丸などない
・ハンマーを持ったら釘に見える
この二つのキーワードですが聞いたことがある人は多いと思います。

銀の弾丸

銀の弾丸は簡単に言えば特効薬のようなものです。
「〇〇を導入すれば開発速度が２倍になる」のような話ですね
これは手段、FW、仕組や技術などHOWの言葉です

私の認識では日本では手段を目的にする人が多い印象です。
「アジャイル開発をするとプロジェクトはうまくいく」
「リモートワークをすれば採用がうまくいく」
「選挙をすれば世の中は良くなる」

うーん、、私としては違和感だらけです。
手段をミスしなければ大丈夫！なんてことありません。

目線を変えましょう

Laravelを使えば高品質なアプリケーションが作れるか？
AWSを使えば落ちることのないインフラが作れるか？
一級建築士の設計書があれば素晴らしい家が建つか？
こう質問するとどうでしょうか？
まぁ９割９分はNOと答えるでしょう、答えてほしい（笑

それは手段とは成功事例を模範するための要素を抽出した具体事例だと思います。
そこをまずは理解しなければなりません。

でもなぜそのような誤解が生まれやすいのか？
ここは推測ですがHOW（具体事例）はわかりやすいのです。
本とかで読むとできる気がする！という効果があるのが具体です。
そして答えと思ってしまいます。

ガンバンの運用方法
Laravelの使い方
糖質ダイエットのやり方
などなど手段の本や情報はあふれている
でもその手段の本質に迫る話って案外少ない印象です

じゃあどういうことが本質でしょうか？
ここは書きません！！
えーーーーーーーーーーーーーーーーーー！

あ、金の弾丸はありまぁす！！
お金つぎ込めば、コンパイル時間が半分になるなど藁

ハンマーを持ったら釘に見える

これもHOWの言葉ですね

ハンマーを持った人はどんなものも釘に見えて叩き込むことを思ってしまうという意味ですね。根本的な課題解決や本質的な解決手段を取らないという比喩です。
自分が持っている手段の選択肢が少ない人はこの傾向があります。
あと過去の成功体験とか失敗体験でバイアスがかかってて手段の選択が固定観念になってたり

・マイクロサービスをRESTful APIでばかり作る
・AWSしか知らない人はGCPやAzuruと比較せずAWSのみで考える
・エンジニアたるもの、Mac以外ありえない
（私の自宅マシンはWindowsです。WSLええよー）

まぁ理解や共感できる人も多いと思います
自分がこの病になっているか？とは気づきにくいものなんです
今でもこの病だったなぁ～と思い返すことは少なくないです

だからチームというのが重要になります。
価値観、経験が全く同じ人はいないからです

・GraphQLってどうだろう？
・gRPCってどうだろう？
・actorモデルもスケーラブルだよ！！Akkaおいしいよ！！
とメンバーが切り込めば検討することができます。

そうやってお互いの知識や経験をうまくミックスし自分たちの最適解を見つけていくことが重要と考えます。

あ、ここは解決方法を一つ提示してしまいました。
答えを簡単に教えるとつまらないものです。

お久しぶりです。餅は餅屋に任せるべき

お久しぶり！！にブログを書こうと思います
いろいろありまして、現在は千株式会社にいます。
そこで新規事業立ち上げやVPoEとしてやっていく中で取り組んだことなどを記事にしていく所存です！！（たぶん続けられるはず、、、

■スピード立ち上げ、コスト効率

これから作る機能実装でリリーススピードや高いクオリティのサービスを作る上での考え方の一つとして共有です
事業開発部は少ない人数のエンジニアで0-1フェーズを戦っている状態です
その上にClipや園チャンネルでは「はいチーズ」が持っている技術アセットとは違う内容の機能実装が多いです。

そのためエンジニアは０から実装すると大変なものもあります。
例として園チャンネルでは動画の公開サービス機能があります。

先生が撮影した動画ファイルをWebでアップーどすると保護者や園児が見ることができる機能です。
この内容をAWSで実現しようとすると、
アップロード（S3）ー＞EMC(media convert）ー＞MediaStore（S3）ー＞Cloudfront
のような一連の処理をざっくり思い浮かべることも出来ると思います。

しかし
・限定公開は動画表示時にパスワードを求めたい！
・回線速度に応じて自動で解像度を落としたい！
・動画プレーヤーはデフォルトのvideoタグでは厳しい！
・ドメインを指定して配信したい！
などなど、、、、多数のやりたいことが出てきます。

これを叶えるためには一工夫だけではなく、開発・運用コストかかることが想像できます。
そこでタイトル通り餅は餅屋に任せるという発想です。

AWSで実装、運用でも出来るわけですが、それを月数千円で実現できるのであれば安いわけです。
そこで採用しているのがVimeoという動画配信サービスです。

詳しくは触れませんが、動画配信についての「やりたいこと」がだいたい用意されていて、APIによる実装が可能です。
そのため、やりたいこと＝APIがあるか？という調査のみで機能実装ができます。

車輪の再発明をなるべく避ける、自分たちで作るならそれなりの強みを作る必要があります。
というお話でした。

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

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

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

さて今回はクラウドの話をしようと思います。
昨今AWS Re:Inventで新たに発表された機能が気になりますが、たくさんのブログで紹介されているので国内クラウドについて書こうと思いました。
AWS、GCP、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を触ってみようぜ！（導入編）

NoSQL

今回は 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)の２種がありますので個別で手順を載せます。

環境

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を指定）の方法が用意されてますが、昨今のクラウドサービスではブロードキャスト通信ができないのでメッシュによる設定をやってみようと思います。
今回は３台あるので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を立ち上げて管理画面を見てみるとジョインしたことがわかります。
ノードが追加されるまでは１０秒くらいかかってそうです。
この時にデータが入っている状態でシャーディングなど起きたらもっと時間がかかると思いますが、今回は試しませんｗ
f:id:eva-hashimoto:20151222165503p:plain

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

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
今回は仕様についての確認は行いませんが後ほどフェールバックの動きやシャーディング動作を検証してみたいと思います。
実運用や各サービス特性にマッチしていれば採用できるポテンシャルは十分にありそうです。（まだテストしてないけどｗ）

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

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

アーキテクチャ MongoDB MySQL

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

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

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

qiita.com

 

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

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

データの鮮度とは？

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

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

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

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

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

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

様々なデータ

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

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

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

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

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

調理法を見極める

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

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

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

調理法の選択

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

RDB（MySQL, Oracle, PostgreSQLなど）

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

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

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

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

 

KVS、NoSQL（redis, MongoDB, Cassandraなど）

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

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

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

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

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

 

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

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

 

データ層で詰まらせない

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

それでは！