タグ

2015年7月30日のブックマーク (6件)

  • Amazon EC2再入門 2015年7月版 | DevelopersIO

    ウィスキー、シガー、パイプをこよなく愛する大栗です。 恒例となってきましたが「Amazon EC2再入門」をアップデートしようと思います。相も変わらずにAWSがアップデートを続けているので記事も最新化します。 最近半年のEC2関連アップデートまとめ 前回の記事から半年の間でEC2に関するアップデートです。成熟したサービスであるEC2でも、まだまだアップデートは止まらないようです。 スポットインスタンスのターミネート通知を試してみた AWSの新サービス SSM を知っていますか? EC2 のAuto Recoveryが東京リージョンにリリースされました Amazon EBSが最大16TB、20000IOPSをサポートしました Amazon EC2の新しい高密度ストレージインスタンス「D2」が出ました [新機能]AMIをCreation Date(作成日)で検索できるようになりました Amaz

    Amazon EC2再入門 2015年7月版 | DevelopersIO
  • Nginxと名前解決の話 - Masteries

    Nginxでは, serverコンテキストのlocationコンテキストにおいて, proxy_passディレクティブを利用することで任意のホストにアクセスを転送することができます. 例えば, serverコンテキストにおいて, location / { proxy_pass http://127.0.0.1:5000; } みたいに書いてあげれば, localhostの5000番ポートにアクセスを転送することが出来ます. Webサービスでは, こういう感じでNginxが443番(HTTPS)や80番ポート(HTTP)で受けたアクセスを5000番ポートなどで動いているWebアプリケーションに転送している訳です. で, このproxy_passディレクティブは, IPをそのまま書くのではなく, 次のようにドメインを書くこともできます. location / { proxy_pass http

    Nginxと名前解決の話 - Masteries
  • はてなで大規模サービスのインフラを学んだ - ゆううきブログ

    中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ

    はてなで大規模サービスのインフラを学んだ - ゆううきブログ
  • このタイミングでシェルスクリプトの基本を学ぶ

    よーしお前ら、今日はシェルスクリプトを勉強するぞ。シェルの種類はbashだ。ただ、他のシェルでも基は同じなので安心してくれ。 シェルスクリプトと言っても、findの使い方とかglob展開とかそういう細かいTIPSはやらん。そういうのは他の記事でも読んでくれ。そうじゃなくて、基的な処理の流れ、考え方の勉強だ。 だいたいシェルスクリプトなんて普段大してやってなくて、いざ必要になったときに「まあPerlRubyみたいなもんだろ」とか軽く考えてたらしょーもないことでハマって時間を無駄にしたりするもんだ。 なんでそんなことが起きるのか。 それはシェルスクリプトの基的な発想が分かってないからだ。PerlRubyのような普通に使われてるプログラム言語とシェルスクリプトの書き方はけっこう違うところがあって、それを理解せずに書いてしまってるからだ。 そもそもシェルとは何かもう一度思い出してみろ。

    このタイミングでシェルスクリプトの基本を学ぶ
  • 普通のデーモンを 1) Server::Starterでホットデプロイ+ 2) slow-restart対応にする - Qiita

    序章 最近筆者があるシステム上の非同期ワーカーに対して作業していたところ、新しいコードをデプロイしてこのプロセス達を再起動すると全てのワーカーが同じタイミングで停止→再起動してしまうのでアラートがちらほら流れてきました。クリティカルなものではないのですが、アラートはうざいです。さらに開発機では何回か失敗もしたのですが、その失敗のせいでワーカーが起動に失敗することもありました。その間は当然ワーカー機能は止まったままです。 アラートはできればみたくないのです。さらに万が一新しいコードが起動に失敗した場合でも前の世代が動いていればこのあたりの心配をする必要がなくなります自分がそのあたりに手を入れるタイミングでServer::Starterをかまして対処してしまうことにしました。 元のワーカー まず前提として、このワーカー達は以下のような形で「実行するワーカーのコマンド名(実際はクラス名)」と「い

    普通のデーモンを 1) Server::Starterでホットデプロイ+ 2) slow-restart対応にする - Qiita
  • あなたのORMの使い方は間違っている

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    あなたのORMの使い方は間違っている