KLab若手エンジニアの これなぁに?

KLab株式会社の若手エンジニアによる技術ブログです。phpやRubyなどの汎用LLやJavaScript/actionScript等のクライアントサイドの内容、MySQL等のデータベース、その他フレームワークまで幅広く面白い情報を発信します。

2013年04月

2013年4月ALMレポート

はじめまして、fukuda-yoです。
KLabで毎月行われているALM(All Layer Meeting)という勉強会のレポートをお伝えします。

ALMとは
ALMとはAll Layer Meetingの略で、職種・役職・発表内容を問わない勉強会・発表会です。
内容的に高度なものである必要はありませんが、発表者自身が工夫した箇所があることを求められます。
また、発表者にはプレゼン練習、聴衆には質問する能力を養う機会を提供する目的もあります。
開催は東京六本木の本社で行われますが、TV会議システム、インターネットを通じて国内外の拠点に配信を行っています。

4月の発表テーマは「障害」ということで、
今までに経験した障害を通して学んだことや注意すべきことについて発表してもらいました。


山田大久「ネットワーク障害のはなし」(福岡より発表)
IMG_2355
まず最初はネットワーク障害についての発表でした。
対象ネットワーク内で運用している全てのサービスが停止してしまった、
という特に影響の大きかったものです。
冗長化された複雑なネットワーク内で外部からの接続ができない状況で
データセンターでハードウェア障害の箇所を特定していく過程を話してもらいました。
途中、一緒に障害対応をしていたCTOの安井からも補足説明があり
普段インフラを触る事の少ないエンジニアには貴重な話となりました。


牧内大輔「ドッペルゲンガー事件」
IMG_2363
あるゲームの対戦イベントで起こった障害で、
本来戦えないはずの自分自身と戦えてしまい、
勝利すると自分のステータスが下がってしまうという障害についての話。
原因はプログラムのバグとインスタンスプールの誤用で
該当バグの説明とともに、
SymfonyでPropelを使った時のインスタンスプールの挙動についても説明してもらいました。
復旧の際に思ったよりも時間がかかってしまったことも反省点として、
これ以降の開発に生かされています。
この障害を通して周りの人に聞いたりいろいろ調べたりして
最終的に自分自身が成長できたことから、
「他案件の障害でも積極的に手伝おう」ということを心がけているそうです。


新田祐介「お正月をかえせ!」
IMG_2379
3番目は年末に起こった障害についての発表でした。
障害が起こった時間はなんと年越し直前。
SQL文のオペレーションミスとバックアップ不備が重なり復旧がかなり難しい状況に。
「なんで正月から仕事してるの?」という家族や親戚からの発言に心を削られながらも
開発・企画メンバーの協力があって、なんとか復旧できたようです。
一人でクリティカルな作業をしないとか、チェック後にコミットするとか
「あたりまえの事をあたりまえにしよう」という教訓を得たそうです。


【特別枠】死にそうになった話
水島和洋「死〜_YASASHISA_2013_Remix」
佐藤雄一「死にそうになった話」
IMG_2392
IMG_2398
今までの経験で死にそうになった時の話をしてもらいました。
各人が危機的な状況からいかにして生き延びる事ができたのかを聞きつつ、
状況(技術的・精神的)の凄まじさに驚愕したりしながら盛り上がりました。

今回のALMは過去の障害について振り返り、
実際に経験しなかった人にも情報を共有する場として
多くのエンジニアが参加し盛り上がりました。
IMG_2380

次回のレポートもご期待ください!

2013年3月度ALMレポート(Amazon様との合同開催)

お久しぶりです、okabe-mです。
KLabでは毎月ALMという社内勉強会を開催しています。今回はALMのご説明と2013年3月度ALMのレポートをお送りします。
※またまた前回のレポートからだいぶ日付が空いてしまいましたが、毎月開催しております。。。

ALMとは
ALMとはAll Layer Meetingの略で、職種・役職・発表内容を問わない勉強会・発表会です。
内容的に高度なものである必要はありませんが、発表者自身が工夫した箇所があることを求められます。
また、発表者にはプレゼン練習、聴衆には質問する能力を養う機会を提供する目的もあります。
開催は東京六本木の本社で行われますが、TV会議システム、インターネットを通じて国内外の拠点に配信を行っています。

先月の3月度は株式会社Amazon様との合同でAWSについての勉強会を開催しました。
発表内容のテーマは、「自分達のAWSの使い方、運用方法」。
弊社と株式会社Amazon様でそれぞれ発表を4人ずつ発表して頂きました。
さっそく、レポートに移りましょう。

Amazon 荒木様「温故知新。巨人の肩を実感する。」
IMG_2047

クラウドコンピューティングが始まる前の科学者のお話。
科学者がデータを保存する場所と解析する場所が世界中にバラバラに置いてあり、解析するのにものすごい不便でした。
今ではS3を使えば一発で解決できますが、当時はなかったので試行錯誤して生まれた解決方法がiRODSという仕組み。

データを保存する際にルールを決めて、取り出す際はいろんなデバイスに対応するために様々なインターフェースを作成し、いろんな要望に柔軟に対応。
まとめるとiRODSは、
・Datagridを実現するミドルウェア
・Datamanagementのインフラストラクチャ
・ポリシードリブンのデータマネジメント

AWSとは直接関係ないですが、S3の仕組みを考える上でも必要な知識でありますので、新たな発見であり目から鱗でした。

KLab株式会社 内川「データベースサーバの性能評価」

※ごめんなさい、写真撮れてなかったです…

データベースサーバの性能をなぜ評価するのか?問題提起から始まりました。
不十分であると、全体の応答に問題が出るかつWebサーバは追加しやすいが、
データベースサーバは簡単には追加できず、大きな改修になりがちなので、サービス本番開始前に十分に検討しましょう。

データベースサーバを評価するにあたっては、実際にサービスで使ってるアプリケーションのDB負荷を評価します。
mysqlのログからSQLを抽出して、記録された通りのSQLを発行するプログラムを作って、一気に実行させるというやり方です。

で、こちらのプログラムをAWSにて提供されている[Provisioned IOPS]というところで動かしてみました。
【AWS発表】Provisioned IOPS for EBS - I/O性能を設定できるEBSボリュームが登場!

実際に検証してみるとあまりパフォーマンスがあがらなかったということです…
ただし、別の構成(SSD+Raid)で検証してみると、50%程のパフォーマンス向上が見受けられました。
KLab側でのアプリケーションの構成上、InnoDBのメモリをいっぱいいっぱい使っているので、I/Oの向上ではあまりパフォーマンス改善に向かないということ。
要は適材適所で、使う場所が正しければパフォーマンスの改善はできる。

まとめ
・データベースの評価はできるだけアプリケーションの動作に近い条件で評価すべき
・最適な設計のためにボトルネックはしっかり把握する
・人から聞いた◯◯を使えば速くなるは鵜呑みにしないこと

Webの世界で有名な言葉「推測するな、計測せよ」がありますが、まさにその通りですね。

Amazon 大谷様「NetflixのクラウドOSS」
IMG_2058

AWSの人間なのにAWSの話をしないということで、Netflixの話をして頂きました。。。

Netflixとは、映画やTVのストリーミング企業。
そちらの会社でのオープンソースの活用を紹介。
全部オープンソースをベースにフルスクラッチで開発しており、GitHubにて公開している。(GitHubのアカウント:GitHub

AWSに頼りきることをせずに、AWSにないものが自分達で作るという思想が大変よいとこのこと。
以下で、Netflixが作ったサービスを紹介。

・Chaos Monkey
AWS上リソースをランダムに停止させるミドルウェア。
柔軟で可用性の高いシステム構築のために、本番環境で常に動かしている
→どうして?
 障害が起こらなすぎるので、障害に耐えるコードを書く気づきが開発者に少ないため。

・ASGARD
オープンソースのマネージメントコンソール。
GUIで一発で変更できるし、いろいろ設定も変えれる素晴らしいツール。
(なぜこれがAWSにないのかという声があったりなかったり…)

他にもAWSを使う上で有意義なツールがたくさん見つかると思いますので、ぜひGitHubのアカウントを参照してみてください!

KLab株式会社 佐々木「じぶんたちのAWS CloudFormationの使い方」

※ごめんなさい、写真撮れてなかったです…

様々なチームで開発を進めるなかで、チームごとに運用しているため、運用ノウハウが貯まりにくい。

そこで、チーム間で共有するテクノロジーとして、
Amazon Machine Image(EC2インスタンスをパッケージングするもの)
AWS CloudFomation(EC2インスタンスや仮想ルータなどAWSのリソースを設計したとおりに起動させる)

そういったものを共有していくうちに他のリージョンへのコピーが手間など様々な課題が見つかったので、
それを解決するためにツールを作ったとのこと。

floccus
既存のAWSのリソースからClooudFomationファイルを生成するCLIツール。
update登録可能にするためにCloudformationファイルを複数とおり生成可能

amimakuo
AMIを別リージョンにコピーするためのCLIツール。
一つのAMIをprivateなままコピーできる
複数のリージョンに同時にコピーできる

こうした自動化は大切ですし、不便であれば自分達で作る姿勢が素晴らしいですね。

Amazon 今井様「120msを巡る闘い。アドテク最新事情。」
IMG_2064

Real Time Biddingという1インプレッションごとに入札が行われる広告配信方式。
1番高い入札金額の広告が表示される。
広告が選択されて配信されるシステムであるDSPというもののお話。

代表的なDSPであるGoogleAdxのタイムアウトは、120msec。
この120msecという制限の中にいかにユーザーへのターゲティング精度をあげるにはどうすればということを
検討した結果が生生しく語られました。
ハードの構成を変えたり、DBのシャーディングなど様々な努力をがなされていて、
中には1msecもかかっていないサービスを提供しているところがあるようです。

広告事業にも様々な技術が使われているようで、大変興味深い貴重はお話でした。

KLab株式会社 松下「AWSチームの話」
IMG_2066

”KLAWS”というKLab独自のAWSの環境を作ったお話です。

RoutingTableを使って冗長化、fluentdを使ったログサーバーの方法や
サーバの一覧を自動生成して、特定のサーバーを表示させるのに活用したり、
Gangliaというサーバー管理ツールを改善して、RDSにも表示させるようになど
細かい改善をして、KLab独自のカスタマイズを実施しています。

Amazon 安川様「EC2上でパケットと戯れる」
IMG_2068

EC2の上でレイヤーの低いところでいろいろ遊んでみたお話の共有です。

RTMetricsというHTTPリクエストとレスポンスをアクセス解析するシステムを
AWSへ以降しようとした際のお話です。

IP-in-IPトンネルを作ってtcでパケットのコピーを流し込むよう設定。
ただし、カーネルで刺さったが、一応パケットは集めることができる。
VPCでもL2レイヤーならある程度は自由が利きます。

ご自身の趣味がパケットキャプチャと仰ってたように、パケットについて細かい細かいお話でした。

KLab株式会社 高田「データ分析グループでのAWS活用について」

IMG_2069

KLabでデータ分析する際の、データ抽出や蓄積、加工にAWSを使っているお話。

様々なソーシャルゲームのKPIのデータをまず、S3に保存。
そこから分析用のec2サーバーに移したり、RDSで加工したりなど行います。

システム構成としては、pythoneによるバッチスクリプト郡で、
サーバー1台とDBサーバー1台とあとはS3に大量のデータがあるだけ。

またec2の活用として、普段は停止しているが、不定期に重たいスクリプトを走らせるときに
動かす分析用サーバーがあったりします。

ApacheのアクセスログをElastic Map Reduce(AWS上でHadoopを利用できる仕組み)を使って
msgpackというフォーマットにバイナリへ高速に変換するのに使っています。

プレゼンの発表中にあった、「データからデータを生み出し、解析に活かしています」という言葉通りの発表でした。


発表内容の紹介は以上ですが、これ以降は懇親会にてオフレコ話やAWSの製品のお話などなどいろいろ飛び交い、大変有意義な勉強会となりました。

こういった勉強会は毎月やってますので、ぜひ次回のレポートも楽しみに!
 KLab若手エンジニアブログのフッター