Giant Swarm Blog | Kubernetes Insights from the team at Giant SwarmGiant Swarm is hitting record on our newest venture: Giant Conversations, the podcast!
実践！ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)
CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障
はじめるDeep learning - Qiita
そうだ、Deep learningをやろう。そんなあなたへ送る解説記事です。 そう言いながらも私自身勉強しながら書いているので誤記や勘違いなどがあるかもしれません。もし見つけたらご連絡ください。 Deep learningとは こちらのスライドがとてもよくまとまっています。 Deep learning つまるところ、Deep learningの特徴は「特徴の抽出までやってくれる」という点に尽きると思います。 例えば相撲取りを判定するモデルを構築するとしたら、普通は「腰回りサイズ」「マゲの有無」「和装か否か」といった特徴を定義して、それを元にモデルを構築することになります。ちょうど関数の引数を決めるようなイメージです。 ところが、Deep learningではこの特徴抽出もモデルにやらせてしまいます。というか、そのために多層、つまりDeepになっています。 具体的には頭のあたりの特徴、腰のあ
アドテク×Scala×パフォーマンスチューニング
アドテク×Scala meetup 2014-11-20 http://connpass.com/event/8384/Read less
ansible 社内お勉強会資料
OpenStack を NetApp Unified Driver と NFS Copy Offload を使って拡張する Vol.002
Go: Building Web Applications With Beego - Part 2 — SitePoint
June 19, 2014Go: Building Web Applications With Beego – Part 2 Welcome back to part 2 of the series, where we get up to speed with the Beego web development framework for Go. If you missed part 1, I encourage you to read it, as it lays the foundation for this series. In part 1, we made a good start, understanding and working with Beego by installing Beego and the command line tool Bee, creating a
Dockerに関するメモ
docker_memo.md Dockerに関するメモ Dockerと付き合っていく上で考えるべきことのメモ The Twelve-Factor App を熟読 http://12factor.net/ http://twelve-factor-ja.herokuapp.com/ (ja) Dockerは要するにこのTwelve-Factor Appを実現するためのインターフェースなので、 選択に悩んだらここに戻ってくると良い。 コードベース (Codebase) バージョン管理されている1つのコードベースと複数のデプロイ 依存関係 (Dependencies) 依存関係を明示的に宣言し分離する 設定 (Config) 設定を環境変数に格納する バックエンドサービス (Backing Services) バックエンドサービスをアタッチされたリソースとして扱う ビルド、リリース、実行 (Bu
事例からAmazon Kinesisとは何なのかを学ぶ | DevelopersIO
はじめに 以前、Amazon Kinesisを使う案件があり技術調査の手伝いをしたことがありました。AWSのサイトには「大規模なストリーミングデータをリアルタイムで処理する完全マネージド型サービス」とありますが、その時は何のためのサービスなのか触ってもいまいちピンときませんでした。その後、分からなかった点を担当者にいろいろ聞いてみたのですが、案件が事例化されましたので教えてもらったことをブログに書いてみようと思います。株式会社あきんどスシロー様の案件です。以下が構成図になります。 「うまいすしを、腹一杯。うまいすしで、心も一杯。」 処理の流れ 事例の構成図からどのような処理が行われているかを担当者に確認しました。 回転寿司のすし皿に付いているICタグの情報を管理端末が読み取ります。 管理端末が読み取った情報はインターネットを経由してAmazon KinesisへPutされます。Putされる
DockerでLinuxデスクトップを使ってみる - GeekFactory
Linuxをサーバ用途に使う場合、クリーンな環境を保つため、XやGNOMEなどをインストールしないことが多いと思います。とはいえ、ちょっとした調査などでデスクトップ環境があれば作業効率が上がるケースもあります。そこで、Dockerを使って、独立した環境でLinuxデスクトップを使えないか調べてみました。 結論としては、XfceやLXDEなら動作しました。GNOMEやUnityは動作しませんでした。日本語入力は要調査です。 とりあえず、DockerでUbuntu Desktopを使うための手順を残しておきます。参考まで。 暫定手順 新しいコンテナを実行します。 docker run -p 5901:5901 -it ubuntu:latest /bin/bash コンテナ内で以下を実行します。 apt-get update apt-get install xfce4 tightvncserv
Web API: The Good Partsを読んだ - AnyType
Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る 業務ではiOSアプリとバックエンドの開発を両方担当しているので、APIの設計を何回かやってきた。しかし、自分なりのやり方でやってきた部分が多かったので、最近発売されたWeb API: The Good Partsを読んでちゃんとした設計について学ぶことにした。 得られた学びをメモとして残す。 HATEOAS HATEOAS（Hypermedia As The Engine Of Application State）という設計方法を初めて知った。HATEOASではまず、サーバー側はレスポンスに関連するエンドポイントを含め次にアクセスするAPIを簡単に辿れるようにする。クライアント側は最初のエンドポイント以
クラウド専業CIerがAWS監視運用でZabbixを使う理由 - サーバーワークスエンジニアブログ
CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを
とあるサイトの高速化についてフロントエンドでやったことまとめ。 - Toro_Unit
業務で携わっている案件なのですが、アクセス数の急増が見込まれるイベントがありまして。準備期間も少なく、バックエンド側でできることがほぼないという状況でサイトを落とさないようにがんばる！というお仕事でした。レガシーソースてんこ盛り。CSSプリプロセッサとか何それ状態。 そこで実施した対策のまとめです。サーバー・アプリケーション・サイトの構成によって、効果の大小はありますが、比較的効果があったと思われるものをつらつらと。 リクエストの削減とファイルサイズの最適化 まず一番最初に考えなければいけないのがリクエスト数です。すごいおおざっぱに言うと、WEBサーバー（ApacheとかNginxとか）への負荷は、PV数×リクエスト数です。PVがそんなに無くてもそのページのリクエストがめちゃくちゃ多いとそれだけでかなりの負荷になります。リクエストを半分にできれば2倍の人数がさばけるってことに、すげーおおざ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSUG 20141127 「Spring Bootを用いたドメイン駆動設計」