mogemoguのブログ

直感型SEとして、日々の事をちびちびと。

「Fluentd meetup in Japan」に参加しました

http://www.zusaar.com/event/193104

感想など

fluentdは導入もプラグインの作成も比較的簡単なようなので、とりあえず、触ってみないと。
社内ネットワークにも比較的簡単に導入できるんじゃないだろうか。ログを残すシーンはあると思うし。
とりあえず、今日の資料はどれも有用なので、後でもう一度見直そうと思う。
関係ないけど、Amazon SQS、Amazon SNSはちょっと気になるから後で調べておこう。

濃密な内容過ぎて、脳が疲れた・・・

以下、適当なメモ・・・

「What's Fluentd? - The missing log collector」 古橋 貞之さん(@frsyuki)

  • 対 Scribe
    • Fluentの方がインストールが楽
      • gem install
      • apt、yum
    • Fluentの方がカスタマイズも楽
      • rubyなので簡単に。変更したら再コンパイルもない
  • 対 Flume
    • masternode、Zookeeperが必要
      • 導入のハードルが上がる
    • 設定が結構たいへん
    • Flumeには設定が一元管理されるため、大規模な場合は、その点では有利
  • アーキテクチャ
    • Input
      • ノンブロッキング
    • Buffer
      • 一番大事
      • データを一定期間貯める
      • チャンクを固めて投げる
      • チャンク送出エラー時のリトライ処理
    • Output
      • 書きだす処理の部分で、拡張が簡単
  • 同梱されているプラグイン
  • テスト用のフレームワークもある
    • MRUnitテイスト
  • Dataは全てTCPで。ただし、HeartbeatはUDPを使用。
  • 文字コード
    • バイナリ
      • MessagePack
  • TREASURE DATA のフレームワーク？
    • AWS上で動作
    • Hive
    • ディスクの使用料の部分はなるべく安く
      • どのようなデータを使うかは、利用直後には分からないかもしれないから
    • 解析部分で課金
  • Bufferの順序は保証
    • ただし、S3などに使用するパラレルモード(2〜3個のチャンクをまとめて投入)の場合は、順序は保証されない
      • S3は書き込みレイテンシが大きい
  • 認証は今のところなし
    • セキュアなサーバでの使用を前提
    • 自前でセキュアに対応するプラグインを作成できる
  • APPサーバにfluentdがあれば、直接MongoDBへ書き込みはできるが、MongoDBに書きこむ前に一度集約することで、負荷の軽減
  • 設定ファイルはAPPサーバ毎になので、大規模でfluentdを使うなら、Puppetなどの構成管理ツールで設定ファイルの管理が必要
    • include http://コンフィグサーバ/　の利用も検討
  • Bufferサイズは制限可能
    • デフォルトは256MB
    • 超えた場合
      • ファイルサイズが超えた
        • ファイルが増える
      • キューの長さを超えた
        • 一番古いものが捨てられる
        • セカンダリという仕組みがあありそちらに
        • ログを絶対になくしたくない場合
          • 入力時にバックアップ用にローカルに保存しておくなどで対処可能
  • Bufferに書きこむところのリトライ機能
    • inputプラグインの実装による
    • AWSを使う場合、EBSが死んだりした場合に起きそう

「Dive into Fluent Plugin」 Masahiro Nakagawaさん (@repeatedly)

  • 柔軟なアーキテクチャ
  • いかにプラグインをうまく使うか？
  • プラグインの作り方
    • Rubyは1.9以上
    • MessagePackを意識して作る
    • Cool.io
      • libev
      • LoopとWatchers
    • Buffer
      • zfileは使わない方がいい。圧縮しかしない・・・？
  • fluentdはmascot募集中
  • 複数行を1リクエストでやりたい
    • tailプラグインのparse lineをオーバーライド。行を溜めて、溜まったら処理
  • CPUの使用率を出したりする場合
    • TimeSliceを使い、60秒毎に処理が走るので、それをWriteメソッドで処理
      • 遅れて到着したものについては、それに対して時間を指定できる

「fluent を使った大規模ウェブサービスのロギング」 舘野 祐一さん (id:secondlife, @hotchpotch)

  • データの規模
    • 1500万UU　PCのみ
    • 110万レシピ
  • このくらいの規模なら転送サーバは1台で十分
  • RPMでfluentdで導入した場合
    • ruby 1.9.2 をインストール。既に入っている、旧バージョンに影響のない形で
  • AWSの話
    • DynamoDB使う？
    • 検討に値する。東京リージョンに導入されたら。
    • DynamoDBはバルクインサートがない。現在、RESTで1件ずつ

「fluentをサービスで使ってみた」 Tetsuya Ohiraさん(@just_do_neet)

  • 運用にまつわる話
    • fluentdが落ちたりした場合は、APPサーバのローカルの生ログから復元
    • プラグインの問題は自分でも直せる安心感

「Distributed message stream processing on fluentd」 Tagomori Satoshiさん(@tagomoris)

  • ログの変換
    • タブ区切り。HiveのLOADで読み込めるから
    • 見せたくない情報のマスクも可能
  • scribelineは軽量
  • scribeプロトコルは重い
  • Linuxの設定は大規模なコネクションを捌けるようにはなっている
    • CentOSのデフォルトのままでは厳しい？なんともいえない

「第2回 ビギナー編 AWS User Group - Japan 東京勉強会」に参加しました

http://atnd.org/events/24493
http://togetter.com/li/251782

感想など

富士ソフトのセミナールーム、綺麗で広くてよかったなぁ。なんか大学の講堂みたいだった。
「プライベートクラウドをパブリッククラウドで」が印象に残ったなぁ。
S3の堅牢性が99.99999999999って魅了だよな。ナインイレブンかっこええ。
国内のクラウトがAWSに勝つのは相当厳しそうだ。国内リージョンもあるし。
顧客がAWS使いたいってケースも増えてきそうだし、触れておいて損はなさそうだなぁ。
これはこれで新しいベンダーロックイン？になるんだろうか・・・。AWSがないと不安でサービス提供できないとかで。
この勉強会に参加したお陰で、AWSに触れたくてうずうずしてる。近いうちにサインアップしたいと思う。
発表者の方々が上手だったってことだなぁ。

以下、適当なメモ・・・

AWS概要 Amazon Data Services Japan 玉川憲さん(@KenTamagawa)

  • Amazonのビジネス
    • Eコマース
    • 物流サービス
    • クラウド
      • AWS
      • 発電所を例えにクラウドの話
      • 自家発電→発電所
        • 発電所から安定した電気を送られてくるので、自家発電は消えていった
      • 実機サーバ→クラウド
        • 実機のサーバもいつか消えて行く・・・？
        • 実機がクラウドに置き換わる例として、発電所の話。分かりやすかった。
  • EC2
    • アカウント作って、クリックしていけば使える←簡単
      • 簡単に使えるってやっぱりすごい武器だよなぁ
    • イメージを選ぶ
      • OS、DB有無など
    • リージョンに南米が
      • Amazonがアマゾン（ブラジルリージョン）に進出
    • 従量課金
    • 即時使用可能
    • トラフィックの急増時も対応可能　数１０台→数千台とか・・・
    • 使わない時に台数を減らせばコスト削減に
      • 夜間に処理が多い場合は、夜間のみ多くの台数を割り当て、昼に台数を減らすことでコストを削減
      • 並列処理をしたい時に、簡単に台数を増やせる
    • 安かろう悪かろうなの？
    • Amazon VPC
    • ELB
  • S3
    • 10TBで月10万円
    • 3箇所に自動バックアップ（東京リージョンなら国内の３箇所）
    • dropboxのバックエンドはS3
  • クラウドの都市伝説！？
    • 従量課金　怖い
      • 見積もり可能。時間単位で
      • 企業が使う場合、きっちり見積りできるのは魅力なんだろうな
      • データの転送量
        • ５〜１５％くらいらしい
    • セキュリティ
    • 移行のしやすさ
      • 商用のライセンス
        • 多くのベンダからサポート
        • ライセンスの買い直しは必要ない
        • VMイメージのインポート、エクスポートも可能
    • 無料使用枠があるので実際に試してみて欲しいとのこと
      • Windowsもある

S3解説 クリエーションライン株式会社 李昌桓さん(@awk256)

  • 赤本、青本の著者の方。
    • 青本は気になる
  • S3上にメモを置いたり
    • インターネットストレージに使用
  • CDNのオリジンサーバ
  • REST／SOPA
  • S3ツール
    • AWS
      • AWSコンソール
      • API
    • サードパーティ
    • CloudBerry
      • 権限をつけやすいのはいいかも
      • 本当にWindowsエクスプローラーだな
      • ログ設定機能も
    • 暗号化
      • 暗号化も速い
      • クリックひとつで
    • バージョニング機能
      • 一定期間で残したりするときいいかも
    • S3はバケット単位
      • バケット名は世界でユニークなものにする必要がある
    • キャッシュサーバ経由も可能
      • キャッシュサーバになければS3から持ってくる

Amazonが提供しているAPIでいろいろできそうだなー
S3は手軽に！エクスプローラーの延長的な感覚で！

EC2解説 株式会社サーバーワークス 柳瀬さん(@oko_chang)

  • 資料 http://www.slideshare.net/serverworks/amazon-ec220120203
  • 料金は１時間単位
  • アベイラビリティゾーン
    • リージョンとHA
    • 簡単にHAを実現、離れたデータセンターを選択するが可能なため
    • タグをつけれる。たくさんのEC2インスタンスを使用する場合などに役立つ
  • 認証用の鍵もWeb上で名前をいれるだけで作成可能
    • ダウンロードしてファイルを保存
  • ポートの開放も機能毎にWeb上で選択
    • SSHやHTTPなど
  • EIP
    • 固定IP
    • インスタンスのスタート・ストップの場合はIPが変更されてしまう
      • 再起動時は変わらない
    • EIPなら接続先が固定
  • EBS
    • サイズ、期間。I/Oで課金
  • 伸縮性
    • EBSからS3にスナップショット→デタッチ→サイズ変更→アタッチ
  • 負荷分散してみよう
    • Webサーバは既にインストールされているAMIからAMIをコピーで簡単に増やせる 
ロードバランサ(ELB) +- インスタンスA　AZ 1
                    |
                    +- インスタンスB　AZ 2

インスタンスに割り当てるAZを異なるものにすることで可用性が上がる
サインアップするまでが勉強会！

QAタイム！

  • 無料使用枠
    • EBSは30GBまで無料。AMIのサイズが超えると課金
      • Windowsの場合はAMIサイズを確認
  • DynamoDBの資料の日本語化は進むらしい

「エンジニアサポート新年会2012 CROSS」に参加しました

「エンジニアサポート新年会2012 CROSS」に参加してきました。

http://tech.nifty.co.jp/party/2012/

セミナーセッションでは「次世代LAMP CROSS」に参加。

http://tech.nifty.co.jp/y/2012/sessions/bRoom1.htm
http://togetter.com/li/248382

以下、適当なメモ・・・

  • Node、MongoDBはは設定をGitで管理しやすい

ちょろっと試したい時とか良いかも

  • githubもいいけど、bitbucketもいい

bitbucketを使ってみないと分からないから使ってみよう

  • CoffeeScript
    • JavaScriptを吐き出すジェネレータ
    • 大勢で使う場合なら、JavaScriptでそれぞれコーディングするより、作られるコードが統一される？
    • CoffeeScriptはプログラミング言語なので、学習コストが掛かる
    • Debug自体はJavaScriptでする必要がある
    • JavaScriptが出来る人にはとっては面倒？

とりあえず一回使ってみようと思う

  • Nodeの良いところ、微妙なところ
    • コールバック
    • 非同期
      • どのように作っても非同期
    • バッチ処理は結構大変、非同期なので
  • MongoDBの良いところ、微妙なところ
    • スキーマの変更にも柔軟に対応
    • スケーラブル
    • Sharding環境で大規模なデータを扱うといろいろと大変らしい・・・

大事なデータは置けなそうですね・・・

パーティーセッションでは「大宴会+LT大会」に参加。

http://tech.nifty.co.jp/party/2012/sessions/bigRoom2.htm
http://togetter.com/li/248493

他のLTもしっかり聞きたかったんですが、ビール飲み過ぎて、あんまりよく覚えてない・・・

全体の感想

  • なかなか勉強になったし、面白いイベントでした。ぜひ来年もやって欲しいなぁ。
  • イベント全体でそれとなとなく気になった点
    • 他セッションの音が少し気になった。
    • 知らない人同士がCROSSするためのセッションがあっても良かったかも。
      • ５〜６人で集まって、何かのテーマについて話し合うとか

「MapR(GreenPlumHD)の中身説明会」に参加しました

「MapR(GreenPlumHD)の中身説明会」に参加してきました。
http://www.zusaar.com/event/198012

エンタープライズ向けのHadoopとして出来は良いと思う。
質問でも出てたけど、ノード毎にライセンスだと、スケールアウトの足を引っ張りそう、お金的な話で
英語力をもっとつけないとダメだなぁ・・・

以下、適当なメモ・・・、資料がもし公開されるなら見直したい

  • UI使いやすそう
  • 空きスロットにプリフェッチすることで待ち時間短縮
  • モニタリングにはganglia
    • MapR用のメトリクスも用意
  • ブラウザからコンソールにログインできる
    • さくらのVPSのリモートコンソールみたいなもの？
  • HdfsをMapRfsに
  • java部分も改良
  • ダイレクトシャッフル
    • HTTPプロトコルをRPCプロトコルに。HTTPよりもオーバーヘッドが少ない
    • Mapの結果は、ノードごとに中間ファイルとして置かれ、それをrpcでやりとり
  • Mapの一時領域にローカルディスクを使わない
    • MapRfs使われるため、すべてのファイルがMapRの枠内で扱われる
    • apache Hadoopがなぜローカルにファイルを出すのか
      • メタデータの更新が辛いから
        • 1ヶ所のnamenodeなので
        • MapRは分散namenodeなので可能
  • rawデバイスを使っている
  • ストレージプール
  • レプリカ
  • コンテナの単位で複数まとめて
    • ボリュームは複数のコンテナ
    • データコンテナ
    • ネームコンテナ
      • メタ情報管理
      • 従来のネームノードで管理したメタ情報を分散
  • コンテナの位置などの管理はCLDB
    • HAできるし、保存している情報も大きくないので、切り替えも早い
    • ネームコンテナはスター型でレプリカ
    • データコンテナは、マスター←→レプリカ←→レプリカ
    • 更新のアクセスがノードに均等になる
    • 中間ファイル用のボリュームは特定のノードしかない。かつレプリカは1個
  • トポロジ
    • ラックを指定できたり
      • あるサービスはこのラックだけとかできる
    • ラックを跨がせたり
  • java api 100%互換
  • 権限など、セキュリティ
    • ファイルなどへのアクセス
    • ボリュームなどの管理
  • スナップショット
    • スナップショットは差分保存
  • ミラー
    • 読み出しの多いアプリでは、ミラーを作っておいて、読み込みにはミラーを使うとか
    • 遠隔地でつくっておくとDRになる
  • ビルトイン圧縮
    • アルゴリズム　lzf
    • ネットワークI/Oも減る
    • 特定の拡張子で除外したりとか
  • ブロックサイズのデフォルトは256MB
  • JobTraker HA
    • 監視はzookeeper
    • 監視プロセスがzookeeperのデータを更新
    • 問題があればzookeeperが別ノードでJobTracker起動
    • 動いているジョブは一時停止するが新しく立ち上がったJobTrackerが引き継いで実行
      • TaskTrackerのタスクがゾンビになったりしない
      • データのごみが残ることでの、ディスクフルが起きなくなるとか
  • NFS機能
    • HDFSデータの出し入れ大変
    • nfsプロトコルのレイヤを一枚挟み
    • 普通にマウントもできる
    • レスポンスも早い
    • viでファイルも作れる
      • おおお、これいいな
  • 細かいファイルが1つのブロックで共有されることも
    • 8KBのブロック
      • これが集まって256MBのブロックサイズってことなのかな？
    • 圧縮もこの単位
  • すべてのサーバーでNFSサービスを起動すると、MapRクラスタが全部見える。
    • ネイティブライブラリから使える
    • ただし、ロックや排他制御はアプリ側で制御しないといけない

「DevLOVE HangarFlight - Snow Barrage -」に参加しました

「DevLOVE HangarFlight - Snow Barrage -」に参加してきました。
http://kokucheese.com/event/index/21611/
まず、オラクルって立派だなぁ。。。綺麗だし。。。無料のドリンクもあるし。。。

以下のセッションに参加しました。

  1. アラ若菜 氏「プログラマになりたくて〜MIRAIGENGOと共に歩んだ365日〜」 @wknar
    • 世界共通言語を実現するために、カヤックにビジネスコンテスト参加して、しかも優勝するってすごいなぁ。
    • ブレークスルーキャンプってあるんですね。実際のキャンプ風景を見てみたいなぁ。参加はしたくないけどｗ
    • MIRAIGENGOについて
      • 共通する連想（ジェスチャー）を集めて世界共通言語にするためのフレームワークだそうな。なんかすごいな。
      • アップロードされた動画のチェックは、著作権的にアウトなものについては、youtube api で弾くとのこと。なるほど。
      • MIRAIGENGOのシステムはどんなスペックのサーバーで動いているんだろう？
      • http://miraigengo.com/
  2. Kenichi TAKAHASHI 氏「Jenkinsの運用を中心にRailsとCI(とサーバ仮想化)について。」→「ビルドを大事に」 @kenchan
    • 「Ganeti」知らなかったなぁ。後で調べておこう。
    • Jenkins
      • IRCを使って、Jenkinsさんとお話か。なるほど。
        • Nicknameはプロジェクト名、prefixはIRCのmentionの形式にか。こういうルールは参考になりそう。
    • 今後は「Travis CI」を使う予定だそうな
      • GitHub用だと、GitHubにお金を払って、プライベートリポジトリで使えないと企業では使い辛いかな。
  3. 荒ぶる四天王決定戦
    • 予算が少なかったのは意外だなぁ。とりあえずアジャイルサムライを読もう、それからだ。
  4. 市谷聡啓 氏「Secret of moon」 @papanda
    • SIerからServicerからSIerの経験から来る話。熱いなぁ。
    • 初期構築費用なし、月々の利用料を払う。
      • ベンダーロックインに近い感じがするけど、違うのかな・・・
    • 情熱プログラマー、U理論がオススメな本らしい。今度、本屋で見かけたら手にとってみよう。
    • 自分を手放せるか、目的に向かい続けることが大事。いいね！
  5. 横田聡 氏 「コミュニティFXUGの立ち上げから、クラスメソッド スタートアップまで。」→「数々の失敗から考える独立と起業」 @sato_shi
    • クロスメソッドという会社の社長さん
    • 独立→フリーター、フリーランス、ニートｗｗ
    • いろいろなアンチパターン。いい勉強になりました。黄色信号を見逃さないようにしよう。
      • 最初に参加した人を上に付けたがるけど、過度な期待、大目に見たりが発生し、後から入った組との軋轢が
        • 以前からの知人はネガティブに取られる
      • トップが率先して、客先常駐する
        • トップが常駐している会社は結構多いようだ
      • 出資話が舞い込む
        • 中途半端な状態で出資を受けるのはあんまりおすすめしない。乗っ取られたりする可能性が高い。
      • バックオフィスを充実させる
        • よくない！人件費かつ固定費
      • 運転資金のために金策に走る
        • 売上が上がっても、下がっても。お金がしばらく経ってから入ってくるケースが多いため、その間のための金策。
      • 名選手＝名監督
        • スーパーエンジニアは、スーパーマネージャーにはなれないかも。適材適所ですね
        • 監督(マネージャ)を増やすとコストが増える
      • 採用を求人会社に頼る
        • 結構、お金が掛かるのであんまりよくない
        • 技術ブログいっぱい書いたほうがマシ
      • 模範的な社会人を目指す
        • 型にはめると生産効率が落ちる
      • 思いが伝わらない組織の階層構造
        • オペレーションは3構造でいいけど、情熱などを伝える場合は直接！
      • 決算で赤字
        • 銀行の見る目が変わる
      • 綺麗なオフィス
        • 引っ越すと家賃上がる→困った
      • 明日のヒント
        • コミュニティでは、聞く側よりも話す側か運営側。
      • ニッチトップ
        • ニッチなものを持っている会社は強い。絶対負けない物を作ろうとすることは大事だよなぁ
        • ユーティリティプレイヤーは特徴がない
      • マーケティングを他社に頼るな
        • 毎月お金が掛かる
      • 全社員が小さな成功体験を重ね続ける
        • 部下やスタッフが脚光を浴びるように
        • 謝るのは偉い人の仕事
    • ノマド推奨とのこと。いいなぁ。
  6. ふりかえり
    • 面識があまりない人と集まって話すのって緊張するけど良いですね！
    • 変わるためのアウトプットとして社内勉強会って良いよみたいな話をしました。社内勉強会勉強会の需要はまだまだありそうだなと感じました。

濃密な1日で、頑張ろうという気持ちが湧きました。
発表者、運営者の方たち、お疲れ様でした〜