AWS の IPv6化について調査は済んだけど、書き始めるのに非常にドンヨリしております。図を書いて少しでも楽しくいきましょそうしましょ。 皆様も読んだらドンヨリするかもしれませんが、できるだけ丁寧に書いてみますので、PublicIP 有料化に抗いたい人は頑張って追ってみてください:-) 目次 また長いです。でもひきかえさないほうがいいかもしれない。 はじめに 前提知識 目的 IPv6 の設計 従来のプライベート IPv4 IPv6 の割り当て Gateway と Routing VPC SecurityGroup Network ACL Subnet Egress Only G/W NAT64 RouteTable Public Private インスタンスで動作確認 IPv6 アドレスの確認 IPv6用の設定 疎通確認 IPv6リソースの配置 既存リソースの入れ替え アプリケーションの
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
gRPCの概要 Googleによって開発され、オープンソース化された通信技術である「gRPC」は、マイクロサービスアーキテクチャにおけるサービス間の通信手段としてはもとより、モバイルアプリがサービスにアクセスするためのインタフェースとしても注目されています。現在ではLinux Foundation傘下のCloud Native Computing Foundation(CNCF)のもとで開発されています。 本連載では、gRPCについて、さまざまなプログラミング言語によるアプリケーションの実装を通じて、技術的な仕様や開発手法を紹介していきます。 RPCとは? gRPCは、RPCという通信プロトコルです。RPCとはRemote Procedure Callの略で、日本語にすると「遠隔手続き呼び出し」となります。RPCは、他の多くのプロトコルと同様にクライアント/サーバ型のモデルを採用しています
One of my Node.js server applications at work had constant 502 errors at AWS ELB (Application Load Balancer) in front of it (HTTPCode_ELB_502_Count). The number was very small. It was around 0.001% of the entire requests. It was not happening on other applications with the same configuration but with shorter response times and more throughputs. Because of the low frequency, I hadn’t bothered inves
Web 開発者は HTTP レスポンスをよく見る。 以前 CDN を導入する際に、キャッシュがヒットしているかどうか、どこのエッジがキャッシュを返しているかを確認するためにヘッダをよく見ていた。また、ヘッダだけではなく、TTFB といったレスポンスタイムも気にしている。とにかく HTTP レスポンスをよく見る。 HTTP レスポンスを確認する3つの方法 Chrome さえあれば DevTools を見て一目瞭然である。 とはいえ、コマンドラインで確認したい時がしばしばある。 GUI を操作するよりも手軽である。 その場合はcurlコマンドを叩けばよい。 これでプロトコル、ステータス、ヘッダが分かる。 また、レスポンスタイムを測りたければ、その名もttfb.shというcurlをラップしたコマンドラインツールがある。 https://github.com/jaygooby/ttfb.sh この
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
夜中のネットが遅い! 怒りの臨界点を超えた僕はOCNに電凸すべく定量的なデータ、つまり通信速度を取得することにしました。 昼間 ダウンロード速度 31.04Mb/s アップロード速度 42.44Mb/s— t_emcee@忙しさ★★★★ (@t_emcee) 2018年2月10日 夜 ダウンロード速度 1.7Mb/s アップロード速度 6.92Mb/s— t_emcee@忙しさ★★★★ (@t_emcee) 2018年2月10日 明らかに速度低下してますね、これは… そんなわけで、このデータをもってOCNに電凸したわけですが、「夜はみんながネット使うから遅くなるよ!あなたが住む地域はインフラ整えてる途中だから、工事を待ってネ!」とカウンターを貰い、あえなく退散することになりました。 状況は何も変わらなかったわけですが、「電凸すると通信速度が上がることもある」というオカルティックなお話も耳に
インフラエンジニアの中西です。 最近プログラマーからこのような話を耳にします。 「ネットワークって難しい/よくわからない」 最近ではAWS,GCPをはじめとするクラウドサービスが充実しているのでWeb界隈のエンジニアはなおさら気にするシーンが少なくなったように思います。 今日は最低限これだけ覚えていたら有事の際にちょっとは役に立ちますよという話が出来たらなと思います。 書式統一のため sudo を省略しています。ご容赦下さい。 コマンド編 ping ping です。疎通確認を行う時のコマンドです。 さすがに分かると聞こえてきそうですね。 例えば、192.168.1.1 というサーバに通信を確認したい場合はこうです。 $ ping 192.168.1.1 繋がる場合はこうなります。 $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 d
最近北米の自宅と日本の実家に VPN を設けていろいろやれたらいいなーと思い、ルーターを物色したらなかなかすごいヤツを発見したので、買ってみました。 EdgeRouter とは 地元サンノゼのネットワーク機器ベンチャー Ubiquiti Networks のルーター製品群です。このルーターはデータセンター等で使われる Linux 系高機能ソフトウェアルーター Vyatta (Brocade の vRouter の源流)R6.3 をベースにした EgdeOS 搭載のルーター製品ですが、信じられないコストパフォーマンスと、 amazon.com での評価が異常に高いのが特徴です。 ちなみに私が買ったのは最廉価モデルの EdgeRouter X ですが、ハードウェアオフロード有効時でルーティング最大 940 Mbps 、IPsec VPN 最大 200 Mbps 、RIP / BGP / OSP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く