タグ

ブックマーク / postd.cc (11)

  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
  • Go言語のリアルタイムGC 理論と実践 | POSTD

    (編注:誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「当にGoを使えば実現できるのか? もしできるならどうやって?」 このブログ記事ではGoのガベージコレクタを、どのように機能し(トリコロールアルゴリズム)、なぜ機能し(こんなに短いGCによる一時停止時間の実現)、そして何よりも、それが機能するのかどうか(GCによる

    Go言語のリアルタイムGC 理論と実践 | POSTD
  • なぜUber EngineeringはPostgresからMySQLに切り替えたのか | POSTD

    はじめに Uberの初期のアーキテクチャは、Pythonで書かれたモノリシックなバックエンドアプリで構成されており、データの永続性のために Postgres を使っていました。当時から比べて今のUberのアーキテクチャはかなり変わっており、 マイクロサービス のモデルや新しいデータプラットフォームになりました。特に、以前Postgresを使っていたケースの多くで、今は Schemaless 、つまりMySQLの上で構築された新しいデータベースのシャーディングレイヤを使います。今回の投稿では、私たちが見つけたPostgresの欠点を探り、MySQLの上でSchemalessと他のバックエンドサービスを構築するに至った経緯について説明していきます。 Postgresのアーキテクチャ 私たちはPostgresで以下のような多くの制約に直面しました。 書き込みでの非能率的なアーキテクチャ 非能率的

    なぜUber EngineeringはPostgresからMySQLに切り替えたのか | POSTD
  • リレーショナルデータベースの仕組み (1/3) | POSTD

    リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術(ビッグデータ、NoSQLJavaScriptなど)を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか? 私は開発者として、理解していないものを

    リレーショナルデータベースの仕組み (1/3) | POSTD
  • Railsアプリを66%スピードアップ ― Railsキャッシュの完全ガイド | POSTD

    (訳注:2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕を一緒にするけれど、当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50~100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング(これは全く別の難物で、あなたのアプリケーションに実装する必要はありません)は、別の機会で扱いましょう。 するべきキャッシングをしない理由

    Railsアプリを66%スピードアップ ― Railsキャッシュの完全ガイド | POSTD
  • 60 (フレーム・パー・) セカンズ:Pinterestの描画パフォーマンス最適化のケーススタディ | POSTD

    今日はWebサイトやWebアプリの描画パフォーマンスをどう改善したらいいのか、ということについて取り上げようと思います。私たちWeb開発者にとって、この分野は比較的新しく注目し始めたエリアで、 ユーザエンゲージメントとユーザ体験 に影響があるため重要です。 フレームレートはWebにも影響がある フレームレートとは、 連続した イメージを端末がスクリーンに映し出すレートのことです。秒間フレーム数(FPS)が低ければ肉眼で個別のフレームを判別でき、FPSの数値が高ければユーザにとっては反応が速いと感じられます。ゲーム業界ではおなじみの概念となっているものですが、Webにも当てはまるのです。 長時間に及ぶイメージのデコード、不必要なイメージのリサイズ、重いアニメーションとデータ処理はすべてフレーム落ちを起こす可能性があり、結果としてフレームレートは下がり、jankが多いページになってしまいます。

    60 (フレーム・パー・) セカンズ:Pinterestの描画パフォーマンス最適化のケーススタディ | POSTD
  • Goで毎分100万リクエストを処理する | POSTD

    Malwarebytes は、驚くべき成長を見せています。1年以上前にこのシリコンバレーの会社に入社して以来、私の主な仕事は急成長するセキュリティ企業の力となるシステムの設計と開発です。日々数百万人が利用する製品をサポートするために必要な、全ての基盤をつくります。私は12年以上、アンチウイルスとアンチマルウェアに関わるいくつかの会社で働いてきました。毎日処理する膨大なデータのせいで、これらのシステムがどれだけ複雑なものになるかを理解しています。 面白いことに、ここ9年ほどで私が携わったWebのバックエンド開発のほとんどは、Ruby on Railsが使われていました。誤解されないように言っておきますが、私はRuby on Railsが大好きですし、すばらしい環境だと思っています。しかし、Rubyでシステムを設計し始めると忘れてしまうのは、マルチスレッド化や並列化、高速化、メモリオーバーヘッ

    Goで毎分100万リクエストを処理する | POSTD
  • Goで使える10のテクニック | POSTD

    ここでは、私がたどりついた最善のやり方を紹介しましょう。個人的に過去数年にわたって大量のGoコードと付き合ってきた経験から集めたものです。これらは全て非常にスケーラビリティがあると思っています。私が、スケールする、と言うときは次のような意味があります。 アプリケーションが求める環境は、アジャイル環境の中で変化していきます。開発の3、4か月後に、全てをリファクタリングする必要が出てくるなど、考えたくもないはずです。新しい機能は簡単に追加できなくては意味がありません。 あなたのアプリケーションは多くの人々によって開発されます。可読性が高く、維持しやすいものでなくてはなりません。 あなたのアプリケーションは大勢の人々に使われます。バグは容易に特定でき、修正できなくてはなりません。 長期的にみるとこれらのことが重要になる、ということを私は今までに学んできました。小さなことであっても、多数に影響しま

    Goで使える10のテクニック | POSTD
  • Dockerコンテナ内でsshdを実行してはいけない理由 | POSTD

    Dockerを使い始めた人がよくする質問といえば、「どうすればコンテナに入れますか?」です。その質問に対して、「コンテナ内でSSHサーバを起動すればいいよ」と答える人たちがいますが、これは非常にマズいやり方です。なぜその方法が間違いなのか、そして代わりにどうすればよいのかをこれから紹介します。 注:記事へのコメントやシェアは、 Dockerブログ にアップされた標準版から行ってください。よろしくお願いします。 コンテナでSSHサーバを起動すべきではない …もちろん、コンテナ自体がSSHサーバである場合は除きます。 SSHサーバを起動したくなる気持ちは分かります。それはコンテナの”中に入る”簡単な方法だからです。この業界の人ならほぼ全員がSSHを一度は使ったことがあります。多くの人がSSHを日常的に使用し、公開鍵や秘密鍵、パスワード入力の省略、認証エージェント、そして時にはポート転送やその

    Dockerコンテナ内でsshdを実行してはいけない理由 | POSTD
  • Dockerにまつわる誤解とベストプラクティスについて | POSTD

    Dockerはシステム界隈に大きな衝撃を与えました。それはシステム管理にとってはまさに大躍進だったのですが、Dockerには、少々、致命的な誤解があるのです。 非常に限定されたアドバイス ここで取り上げるDocker議論は、ほぼミッションクリティカルなシステムにおけるマルチホストのセットアップに限定されたものです(Webサービスが主)。それを念頭においてください。でないと、私からのアドバイスは、他のケースには、おそらく意味をなさないでしょう。 Dockerの背景 この記事では、Dockerとは何か、Dockerの一般的な動作については、すでに基的な知識がある前提で話を進めていきます。 Dockerについて、すべてを網羅するのは、この記事の目的の範疇を越えてしまうので、Dockerについて、自分は初心者だという方は、まずは以下のサイトに目を通してください。 Dockerとは何か? Dock

    Dockerにまつわる誤解とベストプラクティスについて | POSTD
  • サーバの適切な名前の付け方 | POSTD

    現在、 MNX ではクラウドホスティングサービスの新しいデータセンタを立ち上げているところで、とてもバタバタしています。クラウドホスティングサービスは、今の私たちの主な業務ですが、この会社が始まった当初は、Linux管理のコンサルティングサービスを中心としていました。そのサービスを通じて、たくさんの顧客環境を目の当たりにしましたし、それと同じ数だけの、顧客ごとに異なるデバイス名の指定方法も見てきました。そしてもちろん、その全ての指定方法をいいなと思ったわけではありません。名前の付け方は、コンピュータ草創期からの問題ですよね。おのおのがホスト名の指定方法について一家言持っていました。でも、それらの方法は最初のうちはうまくいっても、時を経てシステムインフラが拡大し、状況に応じて変更を余儀なくされるようになると、すぐに扱いにくくなってしまうものがほとんどでした。 そこで今回は、先述した私たちのデ

    サーバの適切な名前の付け方 | POSTD
  • 1