ChatworkがAWSで作られているのは周知の事実でしたが、これだけのものをどう構築しているのかはとても気になっていました。

ガンホーのセッションとどちらにいくかを迷いましたが、日頃お世話になっているChatworkのほうを聞きにきました。

オープンソースの検索ミドルウェアがいくつか選択肢があり、特別なノウハウが無くても検索システムを作ることは可能な時代になってきました。ただしその運用は簡単じゃなく、大量データの投入, 検索速度, バックアップなど課題が多いと思っています。

私も大規模なElasticSearchクラスタを運用していますが、このセッションでもあった通り、心が折れそうになる気持ちは分かります。 その道のスペシャリストになれればよいのですが、それだけの仕事をしているわけではないので・・・中途半端に手を出すとやけどしますね。

そんななかでChatworkがあれだけの規模をなんとか動かし続けているのはCloudsearchのおかげな部分が大きいということです。 やはり少人数で回すには、フルマネージドサービスさま様ですね。。。

Chatowkの規模：4万6千社、41万ユーザー

Chatwork検索システムの変遷

• Mroonga単体構成 2011/9~
• Mroonga分割構成 2013/5~
• Elasticsearch検討 2013/6~
• CloudSearch検討 2014/4~

CloudSearchを採用した理由

• Mroonga 3.0の課題

  • IOロックの発生
  • 一千万件程度では順調
  • 数千万件レベルになるとMySQLがダウンするように。。。

• IOロックを回避するために Mroonga + Spiderストレージエンジンを検討 数億のメッセージ規模で安定稼働させるには、最初から多数のMroongaノードを用意する必要あり

• Elasticsearch 0.9の検証 構成する要素が複雑: クラスター、ノード、インデックス、シャード サイジングが必要 インデックス作成時にシャード数を決める シャード数は後から変更できない

• ダミーメッセージ投入テストを行いながらTry and Error

• シャード分割数が少なすぎ、書き込み速度が徐々に低下、シャード分割数を増やしてデータ再投入

• サイジング対策 インデックスを範囲で区切って細かく分割, シャードも細かく、クラスタ構成も大きなもので

• i2.xlarge x 6の構成を予定

• 課題

  • バックアップｘ
  • Multi-az x
  • アクセス制御 x

もっとカジュアルに検索システムを開発・運用したい。

• 2014/3にCloudsearch大幅アップデートで検証開始
  • 初期投入が十分早い
  • 検索速度も早い
  • Multi-AZ運用が可能
  • Index Fieldごとにアクセス制御可能

CloudSearchを利用した検索アーキテクチャ

キューを通してワーカーがDynamoDBに履歴を作って、それをまとめてCloudsearchに入れる構成

機能要件

• 複数言語対応
• 閲覧権限を持つ全てのGroupChat
• 初期投入対象は3.2億件

• 差分投入で追加、編集、削除を順次行う

• Domain設計

  • Scaling Options:
    • search.m2.2xlarge
    • partition count: 4
  • Index Option
    • (Multiple Language: 特定の言語に依存しない index fieldを一つ用意)
    • 言語ごとにIndex fieldを作成、言語判定ライブラリを用意

• 3.2億件の初期データ投入結果

  • SQSで分割 documents/batch requestを利用
  • c3.8xlargeをworker
  • 30並列で実行
  • 12時間
  • データ投入自体にかかったコストは450ドルくらい

• 差分投入

  • チャットメッセージ編集・追加・削除ごとにSQS作成
  • 一定以上たまったらworkerがまとめて投入
  • この構成で大きな遅延なくindexできている

CloudSearchの課題

• 検索

  • 記号の検索に対応していない
  • アプリケーション側で工夫が必要

• Cloudwatchのメトリクスがない

  • 代替手段として、describe
  • SQSの残キュー数の取得
  • muninを使用

• 認証

  • Scaleoutするためには、現状Proxyが必要
  • access policyはグローバルIPが指定可能だが、即時反映されない、実質４０分程度かかる

• コスト

  • 実質的な運用コストはMroonga分割運用時と比較して約２倍になった
  • リザーブドインスタンスがない

採用してよかったこと

• 保守運用が楽になった
• 差分投入が安定
• 検索速度の安定、高速
• アプリケーション構成がシンプル
• AWSサポートから日本語でサポートを受けられる

ソリューションアーキテクトの大谷さんと開発マネージャの堀さんによる、Kinesisの詳説です。 Kinesisの開発マネージャの方が解説してくれたこともあり、とても意義あるものでした。

Kinesisの新規ローンチ

• 東京リージョンローンチ
• Fluentdプラグイン https://github.com/awslabs/aws-fluent-plugin-kinesis
• MQTTアダプター https://github.com/awslabs/mqtt-kinesis-bridge

事例紹介

• ガリバー http://221616.com/gulliver/news/press/20140715-13667.html
• Pencil(リアルタイムユーザーモニター)
• SmartInsight(Beaconとの距離をロギング)
• Supercell
• bizo

Kinesis詳細

なぜリアルタイム？

• 測定(Metering)サービス　使った分だけ課金されるという特性　オペレーションを測定しないといけない
• 毎秒数千万レコード
• 毎時数テラバイト
• 数十万のデータ・ソース

• 月末にはオーディターでの100%の正確性

• 毎時数百万のファイル

• スケールの課題
• リアルタイムの要望

• 高い運用コスト

• 要求の変化 毎時か毎日のデータ処理が従来の要求だったが、リアルタイム、早い意思決定、KeepEverything、エラスティックな拡張性、複数の目的に応じて同じデータを並行処理したい、などの新しい要求が出てきた。

Kinesis概要

用途単位でStreamを作成し、Streamは１つ以上のShardで構成される Shardは入力側秒間１MB 1000TPB 出力側2mB, ５TPSのキャパシティ 入力されたデータは複数のAZに２４時間保存 Shardの増減でスケール

データ入力

HTTPS/POSt SDK Fluentd Flume Log4J etc

ProducerがPut Recordするサンプル AWS CLIでできる

Shardへの分配ロジック：　md5でハッシュ化して該当のShardに分配される パーティションキーを何にするかは重要

パーティションキーの数 > shardの数 カーディナリティーの高いパーティションキーを使う

シーケンス番号を使って何度でも読むことができる 何度取得してもシーケンス番号の順番は変わらない:重要

データ取得と処理

API Kinesis Client Library/ConnectorLibrary Storm EMR

どうやって信頼性と拡張性のあるアプリケーションを作るの？

• Kinesis Client Libraryを提供
  • Shardと同じ数のWorker
  • Workerを均等にロードバランシング
  • 障害完治と新しいWorkerの立ち上げ
  • shardの数に応じてWorkerが動作する
  • Autoscaling
  • チェックポインティング、At least once処理

これらの煩雑な処理を意識することなく、ビジネスロジックに集中できる

重複データについて

ネットワーク障害や500レベルエラーはリトライをする リカバリやロードバランシングでデータが最後のチェックポイントからリプレイされる

• ユースケースを理解する
  • 冪等なアプリをつくる
  • 重複を許容する

Kinesis Connector Library

S3, DynamoDB, Redshift 4つのインタフェースを使うと簡単に書ける

1つのデータをいろいろなシステムで プロデューサーの負荷軽減 データの一貫性を保ちたい

Kinesisに全てのデータを１回入力する 必要に応じて新しいアプリを追加していく Agilityを高める

Elasticな拡張性

• Streamは１つ以上のキャパシティで構成　Shardでキャパシティプランニング
• SplitShard API Shardを半分に分割

shardやEC2もキャパシティがある ProvisionedThroughputExceededException

shard１つで14$/month Getトランザクションは無料

Ripplationという会社の安藤さんと立本さんによるゲーム運営にAWSのマネージドサービスを活用する話です。 最近のゲーム界隈にうといのですが、「騎士とドラゴン」が代表的タイトルですかね。

とことん運用を楽にする側に振り切っているのは清々とします。

Kinesis – ElasticBeansTalk – S3の組み合わせ方がかなり独特で、二段階に処理を分けるというのはとてもおもしろいと思いました

• いかにして最小人数でサーバー側の開発を行うか

• 以下にしてサーバーコストを下げるか

• スケール・耐障害の自動化

• 監視システムも簡単にしたい

なので、ElasticBeansTalk + DynamoDBのみで構成することにした

AWSを使ってみてわかったこと

• すぐ始められる
• アプリをサーバーにデプロイするまでに流れを作るのが簡単
• 1から整える必要がない
• 思った以上に実用に耐えられる
• ほとんど放置が可能: 最近サーバーをコンソールで調整したくらい

ElasticBeansTalkの注意点

• デプロイ時に一瞬アクセスできないことがある: 気にせずデプロイしている。エラー処理はアプリケーション側で行っている
• オートスケーリングの調整はきっちりしておく

DynamoDBの注意点

• 社内にいるDB技術者の文句やいちゃもんに負けない　問題が出たら後付けで
• バッチ処理をしっかり使う、リトライも行う
• スループットの限界値は急激に変化させられない: 急激な書き込みは読み込みはできない
• バックアップするかどうか　リストアする場合ってどんな状況だろうか

汎用化なんて考えたらダメ

• AWSを使い倒さないと真の良さは発揮されない
• そんなにどれでも動く仕組みって重要なんでしょうか。

ログデータの収集・集計

• 結局、最初はDynamoDBだけでなんとかした

KinesisとBigData

ビッグデータとはなにか

単体ではよくわからないデータこそがビッグデータ

達成課題：毎秒10万件のデータを収集する

Linux TCP 28000個ぐらいのポート TIMEWAIT 60sec 実測値への縫製係数: 0.6 1server 282 req/sec

チューニング後：

Linux TCP 64000 Port TIMEWAIT 10sec 1server 4000req/sec

26台あれば　 3870x26=100620req/sec

ただ、これをどうやって集める？ 一般的なサーバーでつくろうとするとdisaster recovery含めて大変

Kinesisならシャードを100個立てれば終了

Grasslandというツールを開発中: データを分析して

GrasslandでのKinesisの使いどころ

1 クライアントからはKinesisにデータを直接投げる 2 ElasticBeansTalkはS3にキャシュを保存 3 S3はcacheの解析リクエストをKinesisに返す 4 Kinesis –> EBT に解析リクエストを投げる 5 S3 –> EBT はキャッシュを返す 6 EBT –> S3 解析結果を渡す

セキュリティを担保できる工夫はいろいろできる

Kinesisは世界のデータを集めるように作られている

ソーシャルゲームデベロッパーのGraniの河合さんによるC#のウェブアプリケーションの解説です。

私はWindowsでアプリケーションを書いたことも運用したこともないのですが、かなり昔にMS-DOSでシステム管理は少しやったことがあるので、Microsoftの技術には愛着を持っています。

一番驚いたのは、C#の機能をを活かして処理をほぼ非同期で行っているというところでした。 PHPなどでは絶対無理な処理なので、これはすごいなと。 私のプロダクトでやるならScalaになるのでしょうが、ここまでの境地に達するのはよほど言語に精通していないといけない気がします。

ソーシャルゲームのレスポンスで全て100msecを切るように返すことの大変さは分かっているつもりなので、レベルの違いを感じました。 Redisのパイプライン処理いいですね。

とにかくクールだなと思いました。ひたすら感心。

門外漢のC#やWindowsの話をあえて聞いてみてよかったです。

• AWS + C#によるウェブソーシャルゲーム
• C# 50%, AWS 20%, その他 30%ぐらいの話
• AWSだからといってC#を使うのに特別なことはない

using CSharp;

• C#の開発にとことんこだわっている
• もとはPHPだったが開発効率に不満を感じた
• 半年後にC#に全面移行

• AWSを使っていたのでそのまま移行した

• クライアントサイドからサーバーサイドまで全てをC#で！

AWS + C#は全く問題ない。

• 100 server
• 10000 req/sec
• 1000000000pv/day

IIS8 + RDS + Redis(r3.2xlarge)20台

なぜRDBMSを選択するのか

• NoSQLでいい？けれど複雑化をおさえたい
• RDBMSは単純なクエリなら1msec以下で返すがDynamoDBは・・・
• 周辺ツールが充実
• スケールアップや分割で対応できるなら、スケールアウトに固執することもない

何よりRDSが良い

手放し管理、Restore To Point in Timeには救われた

• SQL Server vs MySQL
  • C#としてはSQL Serverのほうが相性はいい
  • しかしRDSとしてみるとSQL Serverは貧弱
  • 今はあるがMulti-AZも無かったし、ProvisionedIOPSの限界値も低かった
  • 結果、MySQLを使っている

r3.8xlargeが最強

垂直分割 vs 水平分割

機能単位の垂直分割を採用

水平分割は避ける: 記述可能なクエリに大きな制限がかかってしまう アドホックなクエリでの集計が不可能になる ほとんどのアプリケーションは、水平分割をする必要はないのでは？

DB管理はGUIで HeidiSQLがおすすめ　phpMyAdminやCUIは積極的にdisりたい

アプリケーションからはMasterのみ参照 いまどきのRDSは十分パワフルなので、Slaveに分散するのは無用な複雑さを生むだけ レプリケーション遅延は起きるので。

同一AZに配置する AZを越えると普段0.5msec程度のクエリが2msec程度になる

C#的な活用としては、コネクションを型で分けるとコンパイルでチェックできる 生のSQLを書いている

テーブル定義から自動生成 テーブルと1:1でひもづいたクラスがある T4テンプレート + ADO.net

半自動生成くらいの位置づけ

• 全階層でのキャッシュの徹底

  • データベース
  • Memcache-Redis
  • Static変数: アイテム名など不変の情報はキャッシュ　
  • リクエスト単位

アプリケーションコードによるJOIN

LINQ to Objectsで簡単。SQLよりもずっと楽

Redis

RDSの不得意な部分を補える 高パフォーマンスなのでMemcached代わりのキャッシュ用途に 用途ごとのグループ分けと単純分散

Master Slave構成をとっている dump出力時にCPUをくうので

ElastiCache Redisは試したときにパフォーマンスがでなかったので使っていない

Protocol Buffersを使っている 高速・省サイズなので

Performance + Async

100msecを切るように作っている C# 5.0を活用

言語構文レベルでサポートされる非同期 同期と同じように非同期が書ける Graniではコード全体が非同期で書かれている

Redisならパイプライン化可能 全てが非同期で自動でパイプライン化される

性能と設計を両立できる

Log for performance

外部通信を全て記録する アプリケーション側で送信前後をフックして記録 後述するGlimpseやSumo Logicで解析する アプリ側でやると負荷がない

Glimpse – 可視化

全体の実行時間のほか、あらゆるメトリックスを常時可視化 http://getglimpse.com

Explainの常時表示　手動でExplainはやらない Redis送受信の表示

日常的開発

Git + GitHub Jenkins DeployはValentia(自社ツール)

Sumo Logicでログ解析 New Relicでモニタリング

Semantic Logging + Redshift + Tableau http://slab.codeplex.com

まとめ

• C# + AWSは現実界
• 構成は堅く、シンプルに
• 環境は常に最新に

ソリューションアーキテクトの北迫さんによる、Cloudfrontの活用方法についてです。

普段RTBをやっているので、相手はユーザーのブラウザではなくてSSPやアドネットワークのAPIで、普段CDNを意識することはあまりありません。 バナー広告の画像やJavaScriptを置いているくらいです。 将来、動画配信とかするなら詳しくなっておきたいなと・・・

ただ現時点でも、劇的にコストや負荷を軽減する方法として、CDNとしてのCloudfrontにはまだ利用シーンがあるのではと思って考えています。

サイト高速化

DNSの仕組みを使って最適なエッジへ誘導 52 Edge locations

80:20の法則 ページ本体のレスポンスタイムは20%に過ぎず、それ以外の部分に80%の時間を使っている

ispとispの間のixのところから足が生える形でAWS edgeがある

CDN Edge Locationの活用

分散型CDNと集中型のCDN

分散型CDN: ユーザーに近いISPのところにEdgeがある キャッシュヒット率が低い傾向 集中型CDN: キャッシュ共有 Cloudfrontはこちら

CloudfrontのEdgeに可能な限りキャッシュさせることが重要

• 静的コンテンツ 805 キャッシュTTLも可能な限り長く、クライアント側にもキャッシュさせる

• 動的コンテンツ 20%

  • ページ共通のもの
  • パーソナライズされたもの
    • 動的に生成されるが、ページ自体は一定期間共通 QueryStringを活用しているもの
    • HTTPヘッダによるページ切り替えしているもの
    • cache-conrtol headerとminimum ttlで調整

キャッシュしすぎるとEdgeを通すオーバーヘッドはないか？ last-modified/ETag ヘッダ if-modified-since 更新なしなら304を返す

• ヒット率向上のための要素

  • キャッシュ時間
  • URLの共通化
  • Etag/Last-modifiedヘッダの活用
  • Query Stringsパラメータの固定化
  • 転送対象Header値の固定化

• Cloudfrontは完全一致でキャッシュを共有

• キャッシュヒット状況はレスポンスヘッダで

  • X-Cacheの値を見る
  • X-Amz-Cf-IdにIDが入る

キャッシュができない動的ページはプロキシとして利用

Dynamic Contens Acceleration

• Post/Put/Header/Cookie対応

CloudfrontのEdgeを経由させても多くの動的ページが扱えるようになった

• Keep-Alive Connection: 3 way handshakeのカット

CDN – Originの間でKeepAliveする HTTPS通信ならSSL Terminationでより効果が大きい

• TCPスロースタート

ネットワークの輻輳を回避するために少しつづパケットを増やしながら量を増やしていく仕組み

• DNS Lookupの高速化

Route53を活用するとLookupが早くなる: Cloudfrontと同じロケーションにサーバーがある –> 近い CloudfrontはAlternative Domain Name: レコードセットのTypeをCNAMEではなくAレコードのエイリアスを利用することでクエリ回数の削減が可能

Cloudfront behaviorの活用 正規表現でURL毎に異なるキャッシュポリシーを適用できる オリジンサーバーのほうで設定をする必要がない　

セキュア配信

• Httpsサポート

• GEO Restriction

• Signed URL(署名付きURL)

  • Cloudfront経由で配信するコンテンツに対して期間指定URLを生成することで、配信コンテンツを保護する機能
  • ポリシーを指定する
  • Origin Access Identity(OAI)を使うと特定のCloudfrontからしかアクセスできないようにできる。一般のサーバーから制限する場合はIPアドレスで(CloudfrontのIPは公開されている)
  • プレミアムコンテンツ配信, Streaming配信などに利用
  • 有効時間の設定は、ダウンロードならサイズにかかわらず短時間でOK　ストリーミングは映像・音声の再生時間+αを設定
  • Behavior毎の設定、正規表現を利用してDistributionを分けなくても特定のコンテンツのみ保護可能
  • Cache-controlヘッダも同様に利用できる

まとめ

• インフラアプローチでの高速化施策
• 動的コンテンツにもうまく活用できる
• セキュアなコンテンツ配信も容易かつ高速化が可能

2014/9/9 AWS Cloud Strage & DB Day http://csd.awseventsjapan.com

Cookpadのエンジニアの青木さんによる、Redshiftの活用方法です。　

さきほどのEMRのセッションも聞きつつも、SQLの世界は深いので、まだまだSQLで頑張れる部分はたくさんあるのではないかと思っています。 Redshiftで可能なことのごく一部しか使っておらず、「Redshiftじゃきつい」というレベルにもまだないです。

ただ、いうほど”リアルタイム”ではなかったです。ユーザーからの検索はリアルタイムで直接SELECTしているみたいですが、データ更新はバッチ処理でした。

User – EC2 – Redshiftという構成になっているのが一番驚きました。「たべみる」がB2Bサービスなのでそれほど同時に使う人数が多くないのでしょうが、こういう構成は無理かなと思い込んでいたのでとても参考になりました。

たべみる: 検索システム

• 単語の検索頻度
• 単語の組み合わせ頻度
• 現在盛り上がっている単語
• ユーザーの年代や居住地域を軸とした分析

「バレンタイン」のキーワード分析　単語の組み合わせ　マッチ度　バレンタイン + 本命, 簡単, 大量

たべみるのシステム構成

User – ELB – EC2 – Redshift

Rails4 / Ruby2.1 dw2.large x 12

目標応答時間 500msec

応答速度向上の施策 圧縮タイプの選択 sort key: where句で入れているものは全てSort Keyに入れる 大きく削るならDist Key, 細かいチューニングはSort key サマリーテーブル: 大きいデータをクエリすると絶対に時間かかるので、サマっておく

サマリーテーブルいつ作る？ 安心と伝統の夜間バッチ 37minで実行できているのでHourlyの更新も可能だが、あえてやっていない。不要なので。 B2Bサービスなので、1日に少しずつ追加されてもあまり意味が無いため。

ログまたはMySQL –> file –> Redhisft(raw –> 中間データ –> summaryの三段階)

データ連携の詳細

信頼と実績のTSV渡し

他の用途ではfluentdによる継続ロードも

SQLによるデータ処理

• ELTのお約束

  • エクスポート禁止:　データ移動は遅い　 DB外処理は非並列
  • UPDATE禁止: 複数回実行しにくい(冪等にしておきたい) VACUUMが厄介
  • 1行INSERT禁止: COPYかINSERT SELECT

• INSERT SELECTだけ使え！！

• SQLでは書けなかった処理

  • 日本語処理　半角→全角変換
  • 可変数カラム　タブ区切り文字列の分割
  • 要するに文字列処理がきつい

• SQLで書ける！ こんな処理

  • 単語の組み合わせ生成 ジョイン
  • 未来の月曜日N週ぶんの生成 ジョイン
  • テーブルの縦横変換 ジョイン
  • 移動平均、移動累積和 ウィンドウ関数
  • グループごとのランキングTOPN ウィンドウ関数

• テーブルの縦横変換の例

• グループごとのランキングの例 ウィンドウ関数を使うと、分割するけど、これを集約せずに結果だけ取ることができる
  • rank() over ( partition by ~ order by ~)

データ更新のパターン

• 差分更新

  • 追加されたデータだけ更新する
  • デメリットは、冪等にしくくいこと
  • そのため、あらかじめ生成されるレンジのデータを消してからデータを挿入する処理にする

• 洗い替え

  • dropまたはtruncateして作りなおす
  • 差分を考える必要がない
  • 遅い
  • 新しいテーブルを作ると権限(GRANT)を1個1個つけて回る必要があり、面倒
  • VACUUM問題

• アトミック洗い替え

  • 新しいテーブルを作ってる途中にテーブルが無くなってしまうので、テーブルが作り終わってからTRANSACTION内でALTER TABLE RENAMEする
  • 24時間参照するテーブルではこれを使う
  • デメリットとしては、データが2倍になってしまう

• 応用：アトミックな本番切り替え

  • 複数のテーブルをいっぺんに切り替える
  • 複数のテーブルがお互いにデータが関連している場合

• 更新パターンの使い分け

  • 生データは差分更新
  • 中間データは洗い替え
  • サマリーデータはアトミック洗い替え

なぜRedshiftにしたのか

• COOKPADがAWSにあるから
• マネージドサービスだから
• 並列処理能力が高いから
• ウィンドウ関数など高度な機能が実装されているから
• ある程度オンライン処理にも耐えられるから

AWSソリューションアーキテクトのJiang yifengさんによるEMRを中心とした技術の詳説です。

私はまだEMRをヘビーに使ったことはなくて、AWSサービスの中でいうとRedshiftのほうをよく使っています。 ただ、EMRのポテンシャルはとても高く、いま最も使っていきたいサービスの一つです。 他のクラウドサービスに似たサービスが無いことも特徴かと思います。

私が最近EMRに注目しているのは、ずっと起動し続けるサービスではデータが収まりきらなくなってきた、という課題があります。 私が取り組んでいるプロダクトでは、一日に約2TBのログが生まれています。圧縮しても数百GB。そうすると、RDSやRedshift, ElasticSearchなどの起動しっぱなしのクラスタにデータを格納し続けるのが困難になってきました。運用もきついですし、コスト的にもきついです。

そこで、古いデータを消していくという運用になるのですが、後から古いデータにアクセスしたいケースはやはりあります。 また、RedshiftでSQL、というだけではこなせないタスクも想定する必要が出てきたため、EMRを検討しています。

デザインパターン

• 一時的なクラスタの活用
• ジョブ実行中のみクラスタが存在

• データはS3に永続化される

• タスクノードの活用

  • Spotインスタンスを使ってコスト削減
  • 短時間で大量のリソースを必要とする場合、S3から大量のデータをHDFSのコピーする際に一時的にタスクノードを追加して、HS1インスタンスなどにデータをロードする手法

ベストプラクティス

• 常に現世代のインスタンスタイプを使用

• ワークロードに最適なノードタイプを選ぶ

  • HS1 HDFS用途
  • I2 and HS1 ディスクIOが多いジョブ
  • 大きめのノードで構成する小さなクラスタが効率的

• 最適なファイルサイズ

  • 小さいファイル(100MB以下)を下げる
  • S3でHadoop利用の場合は1~2GBが最適なファイルサイズ
    • 1mapperからS3のデータ取得速度 10~15mb/s
    • Mapper処理は60秒以上であるべき 60sec * 15mb = 1GB
  • S3DistCpを使ってファイルを結合して最適なサイズに。

チューニング

• 最強のチューニングはデータを効率よく保持すること

• Hadoopはバッチ向け

• Hadoop処理時間の目安は1時間〜数日

• 短いジョブは他の技術がフィットするかも

  • Apache Storm
  • Apache Spark
  • Redshift

• チューニングについて

• ノード追加！！

• ビジネスの価値を最大化する目的からすると一番早い

• Gangliaでクラスタをモニタリング

• EMRなら1クリックインストール

• 例：ネットワークI/O

  • もっとも重要なメトリック。特にS3を使う場合
  • 1つのインスタンスからなるべく多くのネットワークI/Oを引き出す: Mapper数追加
  • Gangliaでネットワークスループットをチェック例えば200mbpsしか使っていなかったらMapperを追加することで改善する可能性が高い

プラットフォームとしてのEMR

HBase

• 書き込みが激しいものに有効

• OpenTSDB

  • HBase上のtime series database
  • 大規模なモニタリング用
  • 秒間数百万のデータ書き込み

• 自動／手動でAmazon S3にHBaseをバックアップ

  • フルバックアップ／増分バックアップ/指定のバージョンに簡単リストア

Impala

• SQL on Hadoop

• Hiveと互換性が高い: 一部のユースケースにおいてはHiveを置き換えられる

• ストレージレイヤー　永続クラスタのHDFSまたはHbaseを使う必要がある。現時点ではS3に未対応

Presto

• ブートストラップでインストール
• Impalaと違い、S3のデータにダイレクトにアクセス可能なところ

Spark

• 非常に光速
• インメモリで処理しきれるならMapReduceより早いケースが多い
• ブートストラップでインストール
• ver0.8をサポート。1.0はcoming soon
• Sparkはメモリを大量に使う。R3系やSpotインスタンスを利用
• CloudWatchでSparkのメトリックスをサポートする JVMの監視が可能
• Spark Streaming + Amazon Kinesisの構成でリアルタイムで分散処理

Ubuntuを使うシチュエーション

Ubuntuに入門したいCentOSユーザーというのは私自身のことです。

最近、Ubuntu Linuxを使いこなせるようになりたいと思う場面が多いです。 普段はCentOSまたはAmazon Linuxを使っていて、Debian系のUbuntuはおそらく全く使えないということはないのでしょうが、なんとなくハードルを感じてしまうところがあります。

前職では最初Ubuntuを使っているシステムがいくつかあったので、厳密にいうと私が最初にログインしてちょっと触ったLinuxはUbuntuでした。 ただそのときは実質的に何もいじらなかった(ログインしたことあるだけ)ので、ソーシャルゲームを開発することになって、CentOSを本気で触り始めたのが最初です。 それ以来、CentOSばかり使っています。

CentOSを勉強し始めたときは、自分でキューブ型PCを買ってきて、自分の部屋においてセットアップしました。 確かCentOSのイメージを落としてきてDVD-Rか何かに焼いて、それを使ってセットアップした記憶があります。

今Linuxのサーバーを新しく作ろうと思った場合、VirtualBox(Vagrant)やDockerがあるから楽です。 そもそもVagrantやDockerをより深く知りたいがためにUbuntuをやろうと思ったという動機もあります。 chefも（最近少なくなってきましたが）Ubuntuのほうがやりやすい部分があったり、Tizenも現状ではUbuntu前提ですよね。

というわけで、Ubuntuも抵抗感なく普通に使えるほうがよさげなのできちんとさわってみることにしました。　

バージョンの違いなど

CentOSだと、いま選ぶのはだいたい5か6系だと思います。 6.4が最新。5.10もStableバージョンで2017年までメンテナンスされる予定ですが、今なら6.4を選んで問題はないでしょう。

Ubuntuのほうですが、このへんを見るに、12か13系あたりが選択肢になりそうです。 13系はまだ安定バージョンが無いようなので、2017年までサポート予定の12.04(コードネーム：Precise Pangolin)を選んでみることにします。

というわけで、それ用のvagrant boxを追加します。(http://www.vagrantbox.es より)

1

$ vagrant box add ubuntu12 http://cloud-images.ubuntu.com/vagrant/precise/current/precise-server-cloudimg-amd64-vagrant-disk1.box

CentOSでは32bitのものをi386、64bitのものをx86_64と呼んでいましたが、Ubuntuでは64bitのほうをamd64と呼ぶようですね。　

vagrantでとりあえず起動してみます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

Welcome to Ubuntu 12.04.3 LTS (GNU/Linux 3.2.0-56-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Mon Nov 18 11:44:43 UTC 2013

  System load:  0.17              Processes:           69
  Usage of /:   2.7% of 39.37GB   Users logged in:     0
  Memory usage: 30%               IP address for eth0: 10.0.2.15
  Swap usage:   0%                IP address for eth1: 192.168.33.11

  Graph this data and manage this system at https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

  Use Juju to deploy your cloud instances and workloads:
    https://juju.ubuntu.com/#cloud-precise

0 packages can be updated.
0 updates are security updates.

_____________________________________________________________________
WARNING! Your environment specifies an invalid locale.
 This can affect your user experience significantly, including the
 ability to manage packages. You may install the locales by running:

   sudo apt-get install language-pack-ja
     or
   sudo locale-gen ja_JP.UTF-8

To see all available language packs, run:
   apt-cache search "^language-pack-[a-z][a-z]$"
To disable this message for all users, run:
   sudo touch /var/lib/cloud/instance/locale-check.skip
_____________________________________________________________________

vagrant@vagrant-ubuntu-precise-64:~$

いきなり親切なメッセージがいろいろ出てきました。

何かパッケージ入れてみようと思い、apacheはCentOSだとhttpdですがUbuntuはapache2というくらいは知っていたのですがあえてapt-get install httpdとやってみると、

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

root@vagrant-ubuntu-precise-64:~# apt-get install httpd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package httpd is a virtual package provided by:
  nginx-naxsi 1.1.19-1ubuntu0.4
  nginx-light 1.1.19-1ubuntu0.4
  nginx-full 1.1.19-1ubuntu0.4
  nginx-extras 1.1.19-1ubuntu0.4
  apache2-mpm-itk 2.2.22-1ubuntu1.4
  apache2-mpm-worker 2.2.22-1ubuntu1.4
  apache2-mpm-prefork 2.2.22-1ubuntu1.4
  apache2-mpm-event 2.2.22-1ubuntu1.4
  yaws 1.92-1
  webfs 1.21+ds1-8
  tntnet 2.0+dfsg1-2
  ocsigen 1.3.4-2build4
  monkey 0.9.3-1ubuntu1
  mini-httpd 1.19-9.2build1
  micro-httpd 20051212-13
  mathopd 1.5p6-1.1
  lighttpd 1.4.28-2ubuntu4
  ebhttpd 1:1.0.dfsg.1-4.2build1
  cherokee 1.2.101-1
  bozohttpd 20100920-1
  boa 0.94.14rc21-3.1
  aolserver4-daemon 4.5.1-15
  aolserver4-core 4.5.1-15
You should explicitly select one to install.

E: Package 'httpd' has no installation candidate

けっこう気が利く感じです。

apache2を入れてみます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

root@vagrant-ubuntu-precise-64:~# apt-get install apache2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common libapr1
  libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap ssl-cert
Suggested packages:
  apache2-doc apache2-suexec apache2-suexec-custom openssl-blacklist
The following NEW packages will be installed:
  apache2 apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common
  libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap ssl-cert
0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,855 kB of archives.
After this operation, 5,681 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://archive.ubuntu.com/ubuntu/ precise/main libapr1 amd64 1.4.6-1 [89.6 kB]
Get:2 http://archive.ubuntu.com/ubuntu/ precise/main libaprutil1 amd64 1.3.12+dfsg-3 [74.6 kB]
Get:3 http://archive.ubuntu.com/ubuntu/ precise/main libaprutil1-dbd-sqlite3 amd64 1.3.12+dfsg-3 [10.4 kB]
Get:4 http://archive.ubuntu.com/ubuntu/ precise/main libaprutil1-ldap amd64 1.3.12+dfsg-3 [8,044 B]
Get:5 http://archive.ubuntu.com/ubuntu/ precise-updates/main apache2.2-bin amd64 2.2.22-1ubuntu1.4 [1,340 kB]
Get:6 http://archive.ubuntu.com/ubuntu/ precise-updates/main apache2-utils amd64 2.2.22-1ubuntu1.4 [90.1 kB]
Get:7 http://archive.ubuntu.com/ubuntu/ precise-updates/main apache2.2-common amd64 2.2.22-1ubuntu1.4 [226 kB]
Get:8 http://archive.ubuntu.com/ubuntu/ precise-updates/main apache2-mpm-worker amd64 2.2.22-1ubuntu1.4 [2,284 B]
Get:9 http://archive.ubuntu.com/ubuntu/ precise-updates/main apache2 amd64 2.2.22-1ubuntu1.4 [1,492 B]
Get:10 http://archive.ubuntu.com/ubuntu/ precise-updates/main ssl-cert all 1.0.28ubuntu0.1 [12.3 kB]
Fetched 1,855 kB in 7s (236 kB/s)
Preconfiguring packages ...
Selecting previously unselected package libapr1.
(Reading database ... 61149 files and directories currently installed.)
Unpacking libapr1 (from .../libapr1_1.4.6-1_amd64.deb) ...
Selecting previously unselected package libaprutil1.
Unpacking libaprutil1 (from .../libaprutil1_1.3.12+dfsg-3_amd64.deb) ...
Selecting previously unselected package libaprutil1-dbd-sqlite3.
Unpacking libaprutil1-dbd-sqlite3 (from .../libaprutil1-dbd-sqlite3_1.3.12+dfsg-3_amd64.deb) ...
Selecting previously unselected package libaprutil1-ldap.
Unpacking libaprutil1-ldap (from .../libaprutil1-ldap_1.3.12+dfsg-3_amd64.deb) ...
Selecting previously unselected package apache2.2-bin.
Unpacking apache2.2-bin (from .../apache2.2-bin_2.2.22-1ubuntu1.4_amd64.deb) ...
Selecting previously unselected package apache2-utils.
Unpacking apache2-utils (from .../apache2-utils_2.2.22-1ubuntu1.4_amd64.deb) ...
Selecting previously unselected package apache2.2-common.
Unpacking apache2.2-common (from .../apache2.2-common_2.2.22-1ubuntu1.4_amd64.deb) ...
Selecting previously unselected package apache2-mpm-worker.
Unpacking apache2-mpm-worker (from .../apache2-mpm-worker_2.2.22-1ubuntu1.4_amd64.deb) ...
Selecting previously unselected package apache2.
Unpacking apache2 (from .../apache2_2.2.22-1ubuntu1.4_amd64.deb) ...
Selecting previously unselected package ssl-cert.
Unpacking ssl-cert (from .../ssl-cert_1.0.28ubuntu0.1_all.deb) ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
Processing triggers for ufw ...
Setting up libapr1 (1.4.6-1) ...
Setting up libaprutil1 (1.3.12+dfsg-3) ...
Setting up libaprutil1-dbd-sqlite3 (1.3.12+dfsg-3) ...
Setting up libaprutil1-ldap (1.3.12+dfsg-3) ...
Setting up apache2.2-bin (2.2.22-1ubuntu1.4) ...
Setting up apache2-utils (2.2.22-1ubuntu1.4) ...
Setting up apache2.2-common (2.2.22-1ubuntu1.4) ...
Enabling site default.
Enabling module alias.
Enabling module autoindex.
Enabling module dir.
Enabling module env.
Enabling module mime.
Enabling module negotiation.
Enabling module setenvif.
Enabling module status.
Enabling module auth_basic.
Enabling module deflate.
Enabling module authz_default.
Enabling module authz_user.
Enabling module authz_groupfile.
Enabling module authn_file.
Enabling module authz_host.
Enabling module reqtimeout.
Setting up apache2-mpm-worker (2.2.22-1ubuntu1.4) ...
 * Starting web server apache2                                                                                              apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName
                                                                                                                     [ OK ]
Setting up apache2 (2.2.22-1ubuntu1.4) ...
Setting up ssl-cert (1.0.28ubuntu0.1) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place

どうやらworkerのmpmだけがインストールされ、さらにapacheが勝手に起動しました(；´Д｀) パッケージ入れただけなのに。。。

1
2

root@vagrant-ubuntu-precise-64:~# /etc/init.d/apache2 status
Apache2 is running (pid 2595).

いきなり勝手が違っててもやもやしてきたわけですが、続く。

Web Api Hackathon Vol.3

2013/11/17に行われた、Web Api Hackathonに行ってきました。私は初参加でしたが、もう3回目で、とりあえずWeb Api叩いて何か作ろうというざっくりしたテーマで行うハッカソン形式のイベントです。 Mashup Awardのコンセプトにも近いですね。

場所はお台場にあるMembersさんのオフィスのラウンジ。机やお座敷やソファのあるかなり大きなスペースで、中央には大きなプロジェクタがあって、裏の隠れたところに昼寝スペースという、個人的にはかなりお気に入りのスペースでした。 リラックマの超大きなぬいぐるみがあったのも印象的でした(写真撮影NGだったのが残念・・・)。

Backlog Kanban – カンバン形式でBacklogのプロジェクトを見る

Backlog というプロジェクト管理ツールがあって、仕事でも利用しています。 1プロジェクト、10人までは無料で使えるので、個人プロジェクトにも利用しています。 このウェブサービスは、ポップなデザインと使いやすいインタフェース、メールに直接返信で課題が更新される、などなどでとても良いサービスなのですが、一点不満があって、それはプロジェクトの概観をしづらいということでした。

なのでこれまではBacklogとは別に、ホワイトボードにポストイットを貼って管理していました。（こういうイメージ ） ただ、これをBacklogで直接やれたらいいのにとつねづね思っていました。

そこで、それを今回のハッカソンで作ってみようと思いたち、そうしてできたのがこちらです。

Backlog Kanban(デモサイト)

http://kanban.kirishikistudios.com/

ソース(GitHub)

https://github.com/backlog-kanban/backlog-kanban

できたというか、まだ全くの開発途中ですが、一応カンバン形式で閲覧するツールとしては動作しています。

Backlog API を使って課題の一覧を取得し、新しいUIに落としただけ、という簡単なものですが、「これがやりたかったんだよ！！」というのができた気がします。

「スケジュールが過ぎたものは赤色で表示される」「課題の種別によって色分け」「課題をクリックするとBacklog本体の課題のぺーじに飛ぶ」などの機能があります。もちろん、Backlog本体側を更新すればその内容はこちらに即座に反映されます。

使った技術はこちら。

• Amazon EC2 (Amazon Linux, micro instance)
• Ruby 2.0
• Ruby on Rails 4.0.1
• rbenv
• apache + passenger

プレゼン資料はこちら。

今後は、

• Backlogアカウントによるログインと閲覧の認証
• 課題の追加・編集機能
• カテゴリや種別の追加・変更への対応

などができるとよいと思います。

デザイン・フロント・サーバーの3人で開発してみて

ハッカソンで、初対面の人たち同士でアプリを作るということをこれまで何回かやってきましたが、本当に難しいと思います。 各メンバーのスキルセットを理解して、何のツールなら熟知しているのか、どこの部分で境界線を引いて分担するのが良いのか、など。 そもそも作りたいものが一致しているのかもすり合わせないといけません。

今回チームを作ったのは3人ですが、みな初対面。 その場で自己紹介をして、基本的な開発手法について議論と相談をして、どう作業するかを決めていきました。

役割分担はこんな感じ。

• @mima-v 全体デザイン、画像制作
• @oogushitakuya フロント部分(HTML,JavaScriptのコーディング)
• @chokkoyamada サーバーサイド(Railsを使ったBacklogAPIの操作、公開用サーバー設定)

アイデア段階から実際のアプリ作成まで8時間弱で、何かできるか不安でしたが、各メンバーがGitHubを使ったワークフローをわかっていたおかげでスムーズに作業が進んだと思います。

作ったアプリを公開する場所があったらいい

Railsに限らずですが、何かアプリを作ったときにそれをグローバルに無料で公開できる場所が少ないなと思いました。 Railsだと有名なのはHerokuですが、PostgreSQLなのがネックだし、他にも選択肢があると良いと思います。

今回は結局AWSでMicroインスタンスを立ててそこにapache入れてpassenger入れて・・・とやったのですが、Microインスタンスにしてもこの１アプリだけを置いておくにはもったいないです。 今後また別のRailsアプリを作ったらこのインスタンスにデプロイしていきたいと思います。

参考リンク

WebAPI Hackathon | デザイナー/コーダーとエンジニアが集まってWeb APIを使ってなにかを作る会 http://webapi-hackathon.info/

Web Api Hackathon Vol.3 – connpass http://connpass.com/event/3890/

2013/06/21 15:00~18:00、デル株式会社主催『次世代ネットサービス向け クラウド・インフラストラクチャ セミナー』というセミナーが行われたので参加しました。Dellもクラウドのセミナーをやるようになったとは時代の流れを感じます。

前半2つのセッションはほとんど聴いていなかったので、後半2つのセッションについて書き留めておきます。

『WEBサービスに最適なクラウド基盤を構成する３つの要素』(クリエーションライン：安田さん)

クリエーションライン という会社、Opscode Chefの日本の正規代理店という点で名前だけは知っていましたが、今回はじめて具体的に業務内容を知りました。

クラウドの導入支援やコンサルティングをしている会社なんですね。OpenStack周りでコミュニティとも関わりの強い会社のようです。

タイトルにある3つの要素とは、下記の3点のことで、ぞれぞれについて解説が行われました。

• プラットフォーム・・・パブリッククラウドか、プライベートクラウドか
• 構成管理(自動化)・・・Opscode Chefを使う
• マネジメント(マルチクラウド)・・・Enstratiusを使う

パブリッククラウドかプライベートクラウドかについては、今回のセミナーはDellのクラウド関係ということで、プライベートクラウドに焦点が当たっていましたが、サービスやチームの性質や規模によってケースバイケースなので、決まった答えはないのかなと思いました。

構成管理ツールについては、私はChef一択ということはないと思っています。Chefは非常に多機能でマルチプラットフォーム対応が柔軟なぶん、やや複雑化しすぎてしまっていると思います。かといってPuppetの勢いはそれほど無いし、またはAnsibleやSaltやCuisineなのかというとそうでも無い気がしています。 言語やDSLがどうというより、「RedHat系Linuxに特化」などある程度OSを絞った形でやらないとchefでいうcookbookのメンテが無理すぎる、というのがchefを1年ほどさわって抱いた感想です。

サイバーエージェントにおけるプライベートクラウド本格導入～その実情(サイバーエージェント：奈良さん)

サイバーエージェント本体のインフラ部門が構築中のプライベートクラウドの内部の解説でした。実際の管理画面やネットワーク図などを含んだ詳細な解説がありました。

とにかく開発スピードの高速化に貢献できるプライベートクラウドを目指すという目的のもと、機能的なメリットよりはシンプルさを追求したものになっています。ディスク以外は冗長化をなるべくせず、アプリケーション側でフェイルオーバーを前提とした作りにするというくだりが印象的でした。

私はこれまで海外事業をやってきたのでこのプライベートクラウドを使う機会は無かったのですが、一応アカウントがあって管理画面入ってみたり仮想サーバーを作ってみたことはあります。

中途半端に中を知っているだけにコメントしづらいのですが、全社的にインフラを共有して効率化とコスト削減を狙うという基本姿勢は大賛成だしその方向でうまくいっていると思います。

AWSと比較されることが多いそうですが、多機能、複雑なAWSに対してとことんシンプルさを追求するサイバーエージェントのプライベートクラウドは、うまく棲み分けできると思います。

ただ独自路線を突き進むよりは、コミュニティ、たとえばOpenStackに追従したほうがいいと思います(ぼそっ

Juju – Ubuntuのクラウドのオーケストレーションツール

セミナーのセッションとは直接関係がないのですが、終わった後の懇親会で、Ubuntuの支援企業であるCanonicalの人が面白いツールを教えてくれました。

Juju
https://juju.ubuntu.com/

オーケストレーションツール(Orchestration Tool)といわれるツールです。

私はUbuntuは使っていないのですが、chefのcookbookがUbuntuベースで作られていることが多いので、Ubuntuを使えば簡単なのにと思うことはたまにあります。その話を振ってみたところ、Jujuの話がでてきました。オーケストレーションツールはchefのような構成管理ツールと同等には重要な存在になると思うのですが、まだ定番といえるものが出てきていません。今後ぜひ調べてみたいと思います。