タグ

ブックマーク / wazanova.jp (65)

  • Prometheus: Go言語で書かれたモニタリングシステム - ワザノバ | wazanova

    https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Prometheusは、SoundCloudが中心となって開発を進めているオープンソースのプロジェクトDockerの社内でもメインのモニタリングシステムとして利用されているようです。 各社のブログのエントリーから、その特徴をまとめると。 多元データモデルとそれを活かす柔軟なクエリ言語 全てのデータにタイムスタンプのある、OpenTSDBに準じたデータモデル。 http_response_500_totalやhttp_response_403_totalなどHTTPレスポンスのステータスごとに用意しなくても

    kimutansk
    kimutansk 2015/01/30
    安易に分散するよりは単体の性能を高められるモニタリングシステムにする・・というのは重要ですね。見てみましょうか。
  • 開発現場における並行処理の留意点 - ワザノバ | wazanova

    https://www.youtube.com/watch?v=RR62KqHEVfM 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Squareが主催した並行処理システムに関するパネルディスカッション。 まずは、並行処理理論で博士号を取得し、Sqaureで分析システムを担当するGian Perroneがハイレベルでの留意点を挙げています。 システム全体で起きていることを自分の頭で完璧に把握しようという姿勢は、正確な並行処理システムをつくる妨げになる。テクノロジーやツールをうまく利用すべき。 並行処理システムを漏れなくテストするというのは相当難しい。 自分で考えて、注意深く対処するというのでは不十分。うまく抽象化に頼るべき。 続いて同社のTamir Dubersteinが、以前データセンタを移行させ

    kimutansk
    kimutansk 2015/01/18
    「並行処理システムは安易に利用されるが、必ず効率的だというのは幻想」は重要ですね。基本的にはやらない方が効率はいい。
  • 立て直しのケーススタディ - ワザノバ | wazanova

    http://jacquesmattheij.com/saving-a-project-and-a-company 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 日次のアクセスが1万人以下なのにサイトパフォーマンスが悪いシステムの立て直しを頼まれたJacques Mattheijjが、5週間で行った対応を紹介してくれているケーススタディです。 システム構成 Rails + PostgreSQL + Redis + AnguarJS + Symfony2 CentOS / HPブレード8台 (128G RAMと複数のVMware)、大型HPストレージアレー、Windowsマシン、Javaアプリ専用マシン 全体所見 アプリは概ね問題なし。システムレベルで非効率が散見され、開発の期限が近づいた時点で、雑な

    kimutansk
    kimutansk 2015/01/02
    高いハードを使用しながら無駄なリソース使ったりして性能でないパターンですか。これはなかなか・・・
  • Javaのせいではなく使い方の問題だという意見 - ワザノバ | wazanova

    http://www.jamesward.com/2014/12/03/java-doesnt-suck-youre-just-using-it-wrong 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 Salesforce.comのJames Wardが、エンタープライズ向けのJava webアプリに長く携わってきた経験からまとめた、「Javaが悪いんじゃなくて、使い方が間違ってる。」というブログのエントリー。 開発環境のセットアップのWikiが10ページもある JDKインストール、SCMレポをクローン/チェックアウト、ビルドを実行/アプリ起動の3ステップであるべき。 一貫してないデプロイ環境 ビルドを、開発 -> ステージング -> 番と進めるにあたりリスクを最小化するために、各環境で変わるの

    kimutansk
    kimutansk 2014/12/24
    Java以外の言語であっても萎える環境なわけで・・・ 言語関係ないですからね。大部分の使い方の問題は。
  • Goと大規模分散システムの相性 - ワザノバ | wazanova

    Googleで分散システムの開発をてがけ、現在はソーシャルメディア mttr.toを立上げ中のBen Sigelmanが、Goを分散システムの開発に利用する場合の、メリットおよびチャレンジについて講演しています。 分散システムのあるべき姿 分散システムの勘所は、最上位ビットをパフォーマンス的にも構造的にもうまく扱うことができるかというのがポイント。その効果が一番大きい。スループットの改善のような詳細は、自分もGoogleでそれに取組んだけれども、9ヶ月くらいたつとハードウェアの性能で解決される可能性が高い。また、構造的にというのは、なるべく小さなコンポーネントを組み合わせたシステムにできるかという意味。 Goのよいところは、 両方、とくに後者によい。Railsだとアプリを複数個用意して並列処理するのは大変だったけど、Goだとシンプルにできて、標準ライブラリも読みやすいとかなどなど。パフォー

    kimutansk
    kimutansk 2014/11/24
    大規模システムにおけるデバッグはGoに限らず対応は大変ですので、大規模分散システムに導入する際の他の言語に対する機能的なNGポイントはほぼない、という感じでしょうか
  • Googleのテスト自動化の進化 - ワザノバ | wazanova

    https://www.youtube.com/watch?v=6ZvCU0dht50 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Google Test Automation Conferenceが今年はSeattleで開催されたようです。その中で興味深いと感じた話題をいくつか拾ってみました。 1) 成長を続けるGoogle 会社の規模が大きくなり、歴史を重ねてくると、何事も非効率になりがちですが、Ankit Mehtaが紹介してくれた数字によると、Googleの開発ペースは依然として右肩あがりのようです。 コードのコミットは、1日3万チェックイン。約3秒に1回。グラフを目測した限りでは昨年から約20%増。 リリース数もこの1年でほぼ倍増。 2) テストクローラーを利用してのモバイル実機テストの

    kimutansk
    kimutansk 2014/10/30
    「データマイニングと機械学習を利用してテストケースを自動作成」と。ログから不変な条件を生成していると。
  • Pinterestをスケールさせる中で学んだこと - ワザノバ | wazanova

    https://www.youtube.com/watch?v=jQNCuD_hxdQ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 PinterestのMarty Weinerによる goto; conference 2014の講演。 「webサイトどうやってつくるの?」という創業期から、現在に至るまで、段階的にテクノロジースタックがどう進化したか。 現在のPinterestのシステムアーキテクチャの全貌。 個別のテクノロジーの選択理由。 などを語った45分のビデオですが、goto; conferenceのサイトからスライドのPDFをダウンロード(初日の10:20のコマです。)できるので、そちらを見ていただいてもわかりやすいかと。 「サイトが落ちてしまうのである意味自然に学ぶことができてしまった。

    kimutansk
    kimutansk 2014/10/28
    「成熟 = 血と汗が注がれたボリューム ÷ 複雑さ 」が深いですね。MongoDBの失敗事例もなるほど。後は「自分たちにとっての複雑さ」が重要ですか。
  • 分散環境でどうなるかはテストしてみないとわからない - ワザノバ | wazanova

    https://www.youtube.com/watch?v=QdkS6ZjeR7Q 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 Kyle Kingsburyは、「クラウドにおいてもネットワークパーティションは起こりうるゆえに、DBなどのプロダクトはマニュアルやマーケティング資料で説明している仕様 & パフォーマンスを、分散環境では必ずしもだせない。」というテーマでの検証結果を公表しているブログのシリーズと、ストレス下での計測ツールJepsenで知られています。ここ1年半ほどで、 PostgreSQL / Redis / MongoDB / Riak / Zookeeper / NuoDB / Kafka / Cassandra / Redis / RabbitMQ / etcd / Consu

    kimutansk
    kimutansk 2014/09/25
    分散システムプロダクトではスペックと実際の動きが異なることは多々あるわけで・・ このあたりのNGポイント挙げは参考になりますね。後はそれが許容できるか否かですか。
  • Twitterのキャッシュを支えるRedis - ワザノバ | wazanova

    https://www.youtube.com/watch?v=rP9EKvWt0zo 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのYao Yuが、大規模サービスのキャッシュにおいてRedisを活用する取組みについて紹介しています。 1) Redisを採用している理由 キャッシュだけで、ストレージとしては利用していない。 主なところでは、Twitterのタイムラインで利用している。ホーム画面であれ、ユーザ画面であれ、タイムラインはTweetのインデックスなので、key/valueストア型のRedisを利用するケースとして最適。 以前はmemcachedを使っていたが、問題になったのは、タイムラインでおきるread/writeは、(ユーザが閲覧している範囲に追加反映するということなの

    kimutansk
    kimutansk 2014/09/20
    Redisはwriteによっているが、クラスタへのwriteは難しい/ディスクやネットワークの前に事前処理を行う、等。 参考になりますね。
  • コードを引継いでどこから手をつけるか - ワザノバ | wazanova

    http://www.se-radio.net/2009/11/episode-148-software-archaeology-with-dave-thomas/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 他人から引継いだコードを把握するのにどこから着手するかというテーマで、たまたまいくつかのエントリーを見かけました。「コードを読み切れないほど膨大にある。」「前任者、経緯のわかる人がいる/いない。」「ドキュメントがある/ない。」など様々な事情が想定されますが、全部まとめて主な声を拾ってみました。 謙虚な姿勢で臨むこと。そのコードベースがわかりづらいのは、書き方が悪いコードだからかもしれないが、自分がその専門領域の知識がなかったり、ベースにあるアルゴリズムが当に複雑な場合もありうる。それを、全

    kimutansk
    kimutansk 2014/09/05
    同僚ということは開発者がいる状態で引き継げる感じですか。でしたらこれで何とかなる?内容自体はその通りだとは思いますが。
  • クラウドのOSを狙うMesos - ワザノバ | wazanova

    https://www.youtube.com/watch?v=r7qN8QwGv2w 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約6時間前 MesosConのキーノートスピーチを紹介します。 まずは、Apache MesosのProgram Chairを務めるTwitterのBenjamin Hindmanが、Mesosの目指す立ち位置について、 現代において「他のコンピュータ」と形容すると、データセンターを指すケースが多い。 アプリを動かすコンピュータという見地からは、PC / タブレット / スマホ / サーバにOSがあるように、データセンターにもOSが必要。 Mesosは、データセンターのOSである。つまり、分散システムにおけるkernelの役割を担う。 そのエコシステムの広がりは、 Mesosとつ

    kimutansk
    kimutansk 2014/09/05
    ステートフルなアプリ用のプリミティブやメンテナンス用のプリミティブは楽しみですね。
  • Dockerイメージの最適化 - ワザノバ | wazanova

    http://www.centurylinklabs.com/optimizing-docker-images/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 米国キャリアのリサーチ部門であるCenturyLink Labsが、 Dockerイメージは1Gを超えることがよくあって、ローカルで実験しているうちはよいが、ネットワークを介して頻繁にやり取りしはじめると、サイズが問題になる。 ということで、dockerイメージのサイズを減らす取り組みについて、ブログで紹介しています。 Layers レイヤの構成の詳細については、Dockerのドキュメントを参照されたし。議論のポイントとして理解しておかなくてはいけないのは、Dockerfileでの各操作の結果、新しいイメージのレイヤが順次生成されるというこ

    kimutansk
    kimutansk 2014/08/04
    いかにレイヤを削るかが全体のサイズを削るための鍵と。そう考えるとあまりDockerfileにバリバリ書くよりは一度実行してexportしたものを使用した方がいいねすかね。
  • Flickr: Redis Sentinelの導入 - ワザノバ | wazanova

    http://code.flickr.net/2014/07/31/redis-sentinel-at-flickr/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 36分前 Flickrエンジニアブログで、Redisのマスター障害復旧を自動化するためにRedis Sentinelを導入した経験を紹介しています。 Redisのユースケース 番サービスに影響を与えないように、写真のアップロード / ユーザ通知 / メタデータの編集などの重たいタスクは、Redisのキューに送られて、非同期でオフライン処理されている。 クリティカルなタスクなので、99.9999%が処理(100万件のうち1件以下)され、99.995%の時間は稼働(月に停止が2分を超えない)させる必要がある。 もし、マスターが落ちると、復旧は手動対

    kimutansk
    kimutansk 2014/08/01
    splig brainシナリオが発生する可能性は0ではないが、リスクよりもメリットの方が大きいと判断したと。そのあたりを天秤にかけて判断できるあたりはさすがです。
  • 大規模分散システムのレスポンスを向上させる工夫 - ワザノバ | wazanova

    https://www.youtube.com/watch?v=1-3Ahy7Fxsc 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約2時間前 GoogleのJeff Dean(Senior Fellow, システム & インフラグループ)による、Velocity Conference 2014のキーノートスピーチです。 Jeffは、オブジェクト指向言語によるプログラムの最適化で博士号を取得。DEC/Compaqの研究所の勤務をへて、1999年にGoogleに入社。以降、BigTable / MapReduce / Spanner / Google Translate / Google Brainなど、同社の大規模分散システムの構築に一貫して携わってきています。 例えば、検索結果のレスポンスを向上させるには、そ

    kimutansk
    kimutansk 2014/07/31
    いかに処理を分割して割り振るかと、突発的に遅いマシンが発生した場合にどう対処するか、ですか。それをこれだけの大規模で実践出来るのはすごいですね。
  • Gilt: Playフレームワークの活用 - ワザノバ | wazanova

    https://www.youtube.com/watch?v=WliXLG2Yo5k 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 GiltにおいてPlayフレームワークをどのように活用しているのか、Giancarlo Silverstrinが紹介してくれています。 単一のRailsアプリからマイクロサービスに切り替える過程で、JVM + Java -> JVM + Scalaと開発基盤を変遷。現在、番環境には、250+サービス。 マイクロサービスへの展開時には、バックエンドのRailsアプリは残すかたちで既存の資産の有効活用。webレイヤでには75+個のアプリ(コード約7万行)がある。リソースとUIテーストを共有したアプリの組み合わせで、Giltのサイトは構成されている。 フラッシュセール(毎

    kimutansk
    kimutansk 2014/07/30
    マイクロサービスの集合体になったためにノンブロッキングな並列処理が実行できることが非常に重要になると。Scalaは適していますね。
  • Shopify: Kafka + Dockerの導入 - ワザノバ | wazanova

    http://company.myshopify.com/blogs/technology/14909841-kafka-producer-pipeline-for-ruby-on-rails 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 オンラインストア & リアルショップ向けのアプリを提供しているShopifyがブログでKafkaの導入について紹介しています。 Kafkaに限らず、Google / Facebook / Twitter / LinkedInなど大手がオープンソースで取組んできたApache系の大規模分散システム向けのソリューションを、他のネット企業もサービスが成長してきたら導入するという話しが続いていますが、このShopifyのように、「魅力的なソリューションに見えるけど、Lin

    kimutansk
    kimutansk 2014/07/29
    コンテナのログを確実に収集するにはやはり外部にキューイングしておくのが1つの解ですかね。そしてKafkaが使用されていましたか。
  • PinterestのHadoopインフラ - ワザノバ | wazanova

    http://engineering.pinterest.com/post/92742371919/powering-big-data-at-pinterest 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 Pinterestもものすごい規模になってきましたね。 1日当たり20TBの新しいデータ。Amazon S3には約10PBが保存されている。 同社ではこのデータの処理にHadoopを利用していますが、 毎日100人以上が、Quoboleが提供するダッシュボードを使って、2,000件以上のジョブを実行。 3,000個のノードで構成される6つのHadoopクラスタを利用。エンジニアは数分で専用のクラスタが立上げ可能。 毎日のログデータは、200億件。約1TBに達する。 このグラフによると、Pinte

    kimutansk
    kimutansk 2014/07/27
    このあたりの求められる性質は運用者も扱いだしたり、マルチテナント化してくると必須の性質になりますね。そして規模はすごい。
  • 何でもデバッグできるようになるスキル - ワザノバ | wazanova

    https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ(apt, yum, gem等)レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい

    kimutansk
    kimutansk 2014/07/21
    「自分がわかってるはずと思うことは全部忘れること」「システムの他のレイヤでのデータも調べること」と後はソース見ろ、ですか。レイヤの詳細は参考になりますね。
  • オープンソースと特許とテスラの決断 - ワザノバ | wazanova

    http://www.teslamotors.com/blog/all-our-patent-are-belong-you 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 今朝テスラがブログで発表した内容は、「オープンソースの精神にのっとり、テスラの保有する特許を他社/他者が利用しても訴訟をしない。」ということ。適用されるオープンソースのライセンスが明示されていないところから考えるに、純粋にオープンソースではなくて、無料もしくは無料に近いかたちでのライセンス契約が必要になるかたちになるのかなと想像してます。 1年ほど前に、ソフトウェアでオープンソースが広がり、サーバ周辺のハードウェアでもオープンソースのプロジェクトが進みはじめた中、製造業のオープンソース化はくるのかという議論をしたときに、私はちょっと

    kimutansk
    kimutansk 2014/06/14
    「ある分野で先行していれば、オープンにした方が戦略的には正しいとなります。けど、この決断は相当勇気が要ります。」・・と。
  • モバイルAPIデザインのまとめ - ワザノバ | wazanova

    Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「 Ruby RoguesメンバとiOSエンジニアAPI議論」で紹介しました。)とEtsyのPaul Wrightの講演のポイントをまとめてくれています。 1) スピード ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。 2) RESTが常にベストとは限らない 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ

    kimutansk
    kimutansk 2014/04/17
    1スクリーン、1APIコール、1セーブ、1 APIコール/サーバ側でサードパーティAPIを扱う/ペイロードごとにバージョン設定/ビジネスロジックはサーバ側/APIはフル準備と。