2017年9月13日水曜日

Redisの水平分割をうまくやるジャストアイデア

Redisをのせているサーバのリソースが逼迫したときに取る戦略の1つとして、水平分割という方法がある。
この水平分割は、データの偏りや、再分割をうまくやろうとすると困難が伴い、泥臭く運用をやる必要がある。

しかし、最初から、クライアントコード上で水平分割の数を決め打ちして扱うと楽になるのではないか？と考えた。
たとえば、サービス開始時には、Redisに将来分割するであろう超大量のユーザIDをキーにしたデータを格納するとして、クライアントは、キーを32分割して扱うようにし、それをすべて1つのRedisに入れてしまえば良い。

メリット：分割しやすくなる。
Redisサーバ数を1から2へ分割するときは、まず、Redis AからRedis Bへレプリケーションを構築して、クライアント上で32分割しておいたキーを、16づつ振り分ける設定をして、レプリケーションを停止する。そうするだけで、サーバリソースをスケールアウトできる。余計になったキーは、あとでバッチで消せばよい。
ノードの負荷の偏りが予想されるときは、Redis Aに20、Redis Bに12を割り当てる、などといったこともできる。

デメリット：最初に決めたRedis分割数までスケールアウトさせたら、その先は泥臭くがんばる必要がある。そうならないように、最初に分割数を多めの数、たとえば、128などに決めておけばよいはず。
分割するとき、1人のユーザIDのデータ更新頻度がレプリケーションのレイテンシを超えるとデータの整合性に不安ができる。アプリケーションによるが、数msで1人の人間がガンガンデータを更新してくることがあるかどうか？この点をクリアできるか、検討する必要がある。

2017年8月28日月曜日

Gitの脆弱性 ( CVE-2017-1000117 ) CentOS yum update

CentOSのyumで最新版のGitをインストールして、Gitの脆弱性 ( CVE-2017-1000117 ) を解決します。
IUSリポジトリを利用して、Gitの最新バージョンをインストールする方法と、公式パッケージのセキュリティアップデート版をインストールする方法の、２通りがあります。
以下、Gitの脆弱性の概要です。
gitクライアント上での任意のコマンド実行の可能性 重要度 - Important
Gitでの"ssh"URLハンドリングにshellコマンドインジェクションの欠陥が見つかりました。
これを利用して、悪意のあるレポジトリや悪意のあるコミットを行われたをレポジトリに対して"clone"アクションをGitクライアントで実行した際に、Gitクライアントを実行したユーザの権限でshellコマンドを実行される可能性が有ります。
https://oss.sios.com/security/git-security-vulnerabiltiy-20170813

IUSリポジトリを利用する場合
 https://ius.io/GettingStarted/
Gitの最新バージョンを提供しています。

IUSリポジトリを設定
CentOS 6 
# rpm -Uvh https://centos6.iuscommunity.org/ius-release.rpm
CentOS 7 
# rpm -Uvh https://centos7.iuscommunity.org/ius-release.rpm
既存のGitを削除して、IUSリポジトリからGitをインストール。 
# yum remove git
# yum --enablerepo=ius install git2u
# git --version
git version 2.14.1


CentOS公式アップデートを利用する場合
https://lists.centos.org/pipermail/centos-announce/2017-August/022519.html
2017/8/17に、CentOS公式がCentOS 6向けのアップデートパッケージを発表しています。Gitのバージョンは1.7.1のセキュリティアップデートになります。

サーバにインストールされているGitバージョンを確認。古いバージョンだった。 
# yum list installed | grep git.x86_64
git.x86_64                         1.7.1-4.el6_7.1                  @base
アップデートをかける。 
# yum update git
バージョンが更新されていることを確認。 
# yum list installed | grep git.x86_64
git.x86_64                         1.7.1-9.el6_9                    @updates

2017年8月7日月曜日

builderscon tokyo 2017 スタッフしてきたのでインスタで振り返る

スタッフパスを頂いたぞ! #builderscon

Takeshi Yakoさん(@takeshiyako)がシェアした投稿 -

アイコンはGitHubのアイコンを使っていただきました。リアル顔とアイコン画像とIDが一致するアイディア。いいですね。

入り口案内。わりふり決定です。 #builderscon

Takeshi Yakoさん(@takeshiyako)がシェアした投稿 -

前夜祭のチーム分けで、入り口案内係になる。4人いたので、1階と2階で割り振ったの図。 @kamadango さんのノート。一瞬でわかりやすく書く能力。

受付準備中です。お待ちしております。 #builderscon

Takeshi Yakoさん(@takeshiyako)がシェアした投稿 -

ノベルティ詰めの作業がなかったので、準備に余裕があった。

前夜祭終了ですね。ありがとうございました。#builderscon

Takeshi Yakoさん(@takeshiyako)がシェアした投稿 -

さくらインターネットの鷲北さんの話がうまかった。当時、ブロックストレージ障害は自分も被ったので当事者感があった。あれはマジでつらい出来事でしたね。。データベースサーバが吹っ飛んで消えてなくなった記憶がある。バックアップとっておいてよかった。

塾生なんですね。

Takeshi Yakoさん(@takeshiyako)がシェアした投稿 -

モヤモヤPOINT。学生と言わない。

トラックC部屋のリーダーになりました。 よろしくお願いいたします! #builderscon

Takeshi Yakoさん(@takeshiyako)がシェアした投稿 -

のんびりスタッフやるかー。と思ってきたら、リーダーだった。完全に油断していました。大きなトラブルはなかったと思われます。頑張った。同部屋スタッフの能力の高さのおかげです。@pastak さんMC力、高し。

CM中。 #builderscon

Takeshi Yakoさん(@takeshiyako)がシェアした投稿 -

なんかこの兄弟、ライブで見たことあるぞと思って調べたら 上鈴木兄弟 だった。思ったよりトラックがかっこ良くて、ついつい音量上げてしまった。うるさかったらすいません。

@慶應義塾大学

Takeshi Yakoさん(@takeshiyako)がシェアした投稿 -

けっこう濃厚です。

2017年6月16日金曜日

Google Cloud Next '17 in Tokyo BigQuery の先進機能

Google Cloud Next のメモです。BigQuery中心にみたのですが、だいたい、入門〜中級へのステップアップTipsみたいな感じで紹介されていました。

以下、『BigQuery の先進機能 : クラウド データウェアハウスの未来を開く鍵』ジョーダン ティガー二氏のセッションのメモです。

・Explanationと仲良くしろ。中で動いているシャードを意識しろ。
・シャッフルを意識しろ。高速に計算できる。quotaに注意。ステージ N から N+1 へのマッピングが統計的に決定できない場合はシャッフルされる。
・大きすぎるJOIN。シャード過負荷になる場合がある。クエリを分割する。
・大きすぎるソート。ORDER BY と LIMITでシャードのリソースを減らして出す。
・大きすぎるカウント。APPROX_COUNT_DISTINCTが早い。正確さ注意。計算結果は概算値となる。エラーレートは 0.3% ~ 1%。内部では、HyperLogLog++を使っている。

写真は、セッションが始まる前のスライドテスト。
（セッション中、となりの人が居眠りしていましたね。。。）

2017年6月5日月曜日

AWS Summit Tokyo 2017キーノートWerner Vogels氏

AWS Summit Tokyo 2017キーノートWerner Vogels氏(Amazon.com CTO)の話のメモです。
全体的に、IoT、機械学習推しでトレンドにのっとった感じです。（Amazon Alexa推しともいえるかも）

・AWSすごい売れています。40%以上のYoY成長（第1四半期、2016年と2017年をくらべて。）10億ドル超のIT企業でトップ成長。
・ゲスト、ソラコムCTO安川氏。AWS使っていますという話。AWSはIoT推したいっぽい？
・ゲスト、NTT東日本の人。オンプレからAWS直結サービス出しました。
・ゲスト、ソニーモバイルの人。AWS IoT使ってます。
・ゲスト、グリーCTO藤本氏。日は昇りまた沈みゆく運命なのだ（超訳）。数千台オンプレサーバを消し去るためにAWS移行をやった。サービスを縮小するためにAWS移行したという話は史上初なのでは。気合。
・AWSは、EC2 FPGAインスタンス、機械学習、IoT、音声認識テキスト吐き出し、テキスト音声データ生成そろってますよ。Amazon Alexa作れますと言っているように聞こえる。内部で作ったAPIとかをAWSで出してくるスピードが早いと思う。

2017年3月9日木曜日

Memory Analyzer / Out of Memory Error

Memory Analyzerがヒープダンプを読むときにメモリ不足で落ちる減少を解消します。

経緯：
Java(Scala)アプリの開発をしているときに、大きめのヒープダンプを取ってMemory Analyzerに読み込ませようとしたら、アラートが出ました。内容は以下のような感じです。
Parsing heap dump from /User/yako/Desktop/heapdump.hprof 17.57.52 has encountered a problem.
An internal error occurred during: "Parsing heap dump from '/Users/yako/Desktop/heapdump.hprof 17.57.52'".
GC overhead limit exceeded

解決方法：
Memory Analyzer起動時に、もっとメモリを持たせてあげれば良いです。

1) jmapでヒープダンプを取得。 
$ jmap -dump:format=b,file=./heapdump.hprof PID
2) Memory Analyzerを起動。 
$ ./mat.app/Contents/MacOS/MemoryAnalyzer -vmargs -Xmx4g -XX:-UseGCOverheadLimit


環境: macOS Sierra

参考資料）
MemoryAnalyzer/FAQ - Eclipsepedia
https://wiki.eclipse.org/MemoryAnalyzer/FAQ

2017年2月7日火曜日

iOS Objective-C SSL証明書エラーを回避する方法

NSURLRequestを使っているとき、SSLで自己証明書（オレオレ証明書）をつかっているサーバのURLにアクセスするとエラーになります。
これを回避する方法です。
開発時などに役に立つTIPSだと思います。

エラーの例
2017-02-07 10:49:25.250 App[46178:1264401] NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
2017-02-07 10:49:25.253 App[46178:1264332] FADHttp failed -1200: https://mydomain/ An SSL error has occurred and a secure connection to the server cannot be made.

Info.plistにAppTransportSecurityを設定して、NSURLRequestをオーバーライドするコードを追加します。

参考資料
[iOS 9] iOS 9 で追加された App Transport Security の概要 ｜ Developers.IO http://dev.classmethod.jp/smartphone/iphone/ios-9-intro-ats/
Working with Apple’s App Transport Security
http://www.neglectedpotential.com/2015/06/working-with-apples-application-transport-security/
Aplle / Cocoa Keys / Information Property List Key Reference
https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40016240
登録: 投稿 (Atom)