AWS クラウドアーキテクチャ - ネットワーク断に強いシステムを構築する - | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、馬場です。 これは、TECHSCORE Advent Calendar 2016 の1日目の記事です。 この1-2年、マイクロサービス・サブシステムに分割し、AWSとオンプレミスを使い分けてシステムを構築しています。システムを運用していく中で、オンプレミス環境/モノリシックデザインのシステムにはない経験をしました。それはネットワークの不安定さによる障害です。 通信障害は発生する前提でシステムを構築する。 AWS関連のさまざまな記事や、このブログでも書かれていることです。 わかっています。わかっているつもりだったのですが、１年間運用してみて、本当に定期的にネットワーク断が発生し、夜中に起こされ、休日に調査したりして、やっぱり1年前の私はわかっていなかったのだな、と感じました。 この記事ではどうやって乗り越えたか、シェアしたいと思います。 リトライする 基本は「リトライ」 ネットワ
CloudflareのサーバーはもうIPを所有していません。では、どのようにインターネットに接続しているのでしょうか？
データセンター内のIP共有サーバー間でIPを共有するという考え方は新しいものではありません。ルーター上のSource-NATで実現してきた方法です。残念なことに、必要なエグレスIPの数が非常に多く、また運用のサイズも大きいため、ルーターレベルでステートフルファイアウォールまたはNATに依存できません。また、当社は共有状態を好まないので、NATの分散インストールは避けたいところです。 代わりに選択したのは、ポート範囲によるサーバー間におけるエグレスIPの分割です。特定のエグレスIP に対して、各サーバーは使用可能な送信元ポートのごく一部（ポートスライス）を所有します。 インターネットからリターンパケットが届くと、それを正しいマシンに戻すルーティングをしなければなりません。このタスクのために、L4 XDPベースのロードバランサーである "Unimog "をカスタマイズしました。当社のL4 XD
RFC 9113 日本語訳
この文書は「RFC 9113」の日本語訳です。 原文の最新版は、この日本語訳が参照した版から更新されている可能性があります。 この日本語訳は参考情報であり、正式な文書ではないことにも注意してください。また、翻訳において生じた誤りが含まれる可能性があるため、必ず原文もあわせて参照することを推奨します。 公開日: 2022-08-08 更新日: 2022-08-08 翻訳者: Moto Ishizawa <[email protected]> 概要 この仕様は、HTTP バージョン2 (HTTP/2) と呼ばれる、最適化された Hypertext Transfer Protocol (HTTP) のセマンティクス表現について説明します。HTTP/2 は、フィールド圧縮を導入し、同一接続上での複数同時通信の実現により、ネットワークリソースのより効率的な利用とレイテンシの削減を可能にします。 この
HTTPとRESTの基本 『網羅版：HTTPメソッドとレスポンスコード』 - Qiita
初めに 参考サイト：HTTP 意味論（共通基盤）RFC 9110 — HTTP Semantics 参考サイト：開発者向けのウェブ技術 > HTTP レスポンスステータスコード 参考サイト：Wiki HTTPステータスコード 参考書籍：Webを支えWebを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) 参考書籍：オライリー・ジャパン RESTful Webサービス 各文献を元にまとめした。『3. HTTPレスポンスコード概要』以降は引用まんまに近いところもあれば、大幅に書き換えた・再構成した部分も多々あります。 この記事を書こうと思った切欠はステータスコードについて質問された時にちゃんと答えられなかったからです。 次は、これを元に RESTful API の設計の記事とか書いてみようと思います。 また、この記事は一応3部作です。特に第1部で
HTTPとRESTの基本 『網羅版：HTTPメソッドとレスポンスコード』 - Qiita
初めに 参考サイト：HTTP 意味論（共通基盤）RFC 9110 — HTTP Semantics 参考サイト：開発者向けのウェブ技術 > HTTP レスポンスステータスコード 参考サイト：Wiki HTTPステータスコード 参考書籍：Webを支えWebを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) 参考書籍：オライリー・ジャパン RESTful Webサービス 各文献を元にまとめした。『3. HTTPレスポンスコード概要』以降は引用まんまに近いところもあれば、大幅に書き換えた・再構成した部分も多々あります。 この記事を書こうと思った切欠はステータスコードについて質問された時にちゃんと答えられなかったからです。 次は、これを元に RESTful API の設計の記事とか書いてみようと思います。 また、この記事は一応3部作です。特に第1部で
TLS 1.3 学習ノート
はじめに これは筆者が TLS 1.3 を学習した時のメモを記事にしたものです。 内容の正確性は担保できませんので、あらかじめご了承ください。 参考にした書籍 プロフェッショナルSSL/TLS (ISBN: 978-4-908686-00-9) ラムダノートでを購入するとダウンロードできる特別版PDFも参照しています 徹底解剖 TLS 1.3 (ISBN: 978-4-7981-7141-8) 参考にしたウェブサイト うるふブログ | wolfSSL Wikipedia IT用語辞典 e-Words TLS とは？ TLS は Transport Layer Security の略で、インターネット上で安全に通信を行うためのプロトコルです。 インターネット上で安全に通信を行う必要性 前提として、インターネットはセキュリティが考慮されていません。 もともとインターネットは、大学間で少数のノー
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
Module ngx_http_upstream_module
Defines a group of servers. Servers can listen on different ports. In addition, servers listening on TCP and UNIX-domain sockets can be mixed. Example: upstream backend { server backend1.example.com weight=5; server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; server backup1.example.com backup; } By default, requests are distributed between the servers using a weighted r
WPA2の脆弱性 KRACKsについてまとめてみた - piyolog
2017年10月16日、WPA2のプロトコルに欠陥が確認され盗聴や改ざんの恐れがあるとして脆弱性情報が公開されました。発見者によりこの脆弱性は「KRACKs」と呼称されています。ここでは脆弱性の関連情報をまとめます。 脆弱性タイムライン 日時 出来事 2017年5月19日 Vanhoef氏が研究論文を提出。 2017年7月14日頃 Vanhoef氏が脆弱性の実験をした製品開発ベンダへ連絡。 その後 Vanhoef氏が影響範囲の広さを認識し、CERT/CCと協力し脆弱性情報を開示。 2017年8月24日 ラスベガスで開催されたBlackhatでVanhoef氏が関連研究を発表。 2017年8月28日 CERT/CCから複数の開発ベンダ*1に通知。 2017年10月6日 BlackhatのTwitterアカウントがWPA2をテーマとした発表があるとツイート。 2017年10月16日 SNSなど
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
