「AKIBA.AWS #6 ネットワーク x 基礎編 – VPNとDirectConnect -」に行ってきました

AKIBA.AWS #6 ネットワーク x 基礎編 – VPNDirectConnect –

https://classmethod.connpass.com/event/84401/

に行ってきたので、そのときのレポート

1. 日本でAWS Direct Connectを利用する話

資料

 

以下、講演を聞きながらのメモ

想定する聴講者

ネットワークはあまり詳しくないけど、AWSを使ってみたいIT技術者

ネットワークセキュリティとその設計

Direct Connectはオンプレとクラウドを繋げるサービス

 

インターネットは怖いのでセキュリティをしなければいけない。

コンピュータセキュリティは大きく分けて2種類ある

エンドポイントセキュリティ

 → ウィルス対策ソフトを入れたり

ゾーンセキュリティ

 → 企業などが、自分の管理下のネットワークを置いて、そこで管理すること。
プライベートなネットワークのこと。

 → 組織内の人のみアクセスできるプライベートネットワーク。専用の箱を作って管理。

 → 誰でもアクセスできるパブリックネットワークとの境界を
しっかり分けて管理しましょうということ。

 → 会社の場合だと、ルータがその境界になっていたりする。

家庭のネットワークと企業のネットワークの違い

会社のネットワークは、システムの用途などでプライベートネットワークが別れている。

オフィスのLANとデータセンターで別ネットワーク。

それぞれのプライベートネットワークをどう繋ごうかと考えたりする。

拠点間プライベートネットワーク

方法としては大きく2種類ある

インターネットVPN

安価でベストエフォート

パブリックなインターネットを経由して行うが、組織内の通信を暗号化することにより実現。

インターネットを経由して行なっているので、使い勝手も特に差異はない。

IP-VPN

高価・高セキュリティで帯域保証つき

インターネットベンダーの設備を経由して、閉じた通信網のなかで行う通信。

 → 昔は、ビルとビルの間に線をつないで、、、とかやってる時代もあった。

 → いまは、ネットワークベンダーの設備を使ってやったりしている。

 

Ethernetであれば、ネットワーク通信自体の要件に違いはない。

セキュリティレベルや品質で選択する。

クラウドのネットワーク設計

いわゆる、VPCの話。AWSVPCはどういうつくりなのか?

VPCとは

AWSで使えるネットワーク機能

ざっくりいうと、AWSで使えるネットワーク機能が詰まったもの。

 

VPCの便利なところというのが、

パブリッククライドとしては、東京リージョンということで共通で使うのだが、

ユーザごとにネットワークを切って使うことができる。

 

それぞれのVPCは独立していて、閉じた仮装プライベートネットワーク。

やろうと思えば、VPC同士の接続(ピア接続)もできる。

 

本番と開発のネットワークを分けたいというような形で使われることが多い。

本番のネットワークのセキュリティレベルはあげたいが、

開発用はポコポコサーバーを建てたい、など。

 

VPCとプライベートネットワーク(社内の環境)との相互接続を実現するために

AWSが提供しているDirect Connectというのがある。

 

VPCとプライベートネットワークを繋げる手段は3

  • VPCのインターネットVPN機能
  • EC2でインターネットVPNソフトウェアを実行
  • AWS Direct Connect (今回のメイン

Direct Connectの特徴

  • 高品質
  • 高セキュリティ

サービスとしてのSLAは未定義なため、

現状は、月のアクセスがどのくらいまで保証、というのが明示されていない。

AWSによるサービスのメンテ頻度など実績で比較する。

Direct Connectはメンテ頻度が少ないので、安定しているなど。

対して、インターネットVPNというのが、構築も簡単で手軽である。

AWS Direct Connect

日本で使えるところ。

  1. エクイニックス ty2(東京 東品川)
  2. アット東京 cc1(東京 新豊洲)
  3. エクイニックス os1(大阪 四つ橋)

AWSのリージョン(東京・大阪)とは別

コラム

Direct Connectがある場所に、日本のAZがあるの?という質問がよくある。

真実はわからないが、違うというアナウンスがされている。

Direct Connectの使い方

Direct Connectが提供してくれるのは全てではなく、

VPCから、先ほどの3箇所(エクイニックスty2、アット東京cc1、エクイニックスos1

までの通信が用意される。

 

その3箇所のところにLANの差込口があるので、そこまでは繋ぐよ。

そこから自社のネットワークまでは、自分で用意してね。っていうようになっている。

自社のネットワークまでの繋ぎ方は2種類ある

占有プラン

3つのいずれかのデータセンターと通信を自前で行なって

IP-VPN接続などをする。

自社内のプライベートネットワークの中に

3つのうちのデータセンターへの口を用意する。

メリット

ユーザが自分でいろいろ設定するので、制約は少ないというメリットがある。

 → たとえば、複数のネットワークベンダーからデータセンターに繋ぐということもできるし、

   いくつものVPCを繋げるということもできる。

デメリット

価格が高いこと

共用プラン

ネットワーク事業者が、3つのうちのデータセンターとクラウドとの接続をやっているので、

自社内からそのクラウドに対して、IP-VPN接続を行う。

メリット

占有プランと比べて、データセンターとのやりとりコストや予算などが抑えられること。

デメリット

制約が多いことと、接続できるVPC数が1つだけであること。

まとめると

  • 共用プラン:比較的手軽
  • 占有プラン:本格利用

とっかかりはどうするか?

Direct Connnectを使いたいとなったら、既存のネットワーク事業者の営業さんに相談をする。

 → 中には、Direct Connectの経験があるネットワークベンダーもある。

 → AというネットワークはIP-VPN接続でやって、
   Bというネットワークはネットワークベンダーにお願いして、というようなやりかたもある。

技術的な不明点があれば、質問したり、AWS専用線アクセス体験ラボの活用がおすすめ

おまけ

  • Direct Connect応用機能
    → 占有プランでないと使えなかったりする。
  • パブリック接続
  • Direct Connect Gateway
  • Lag

まとめ

  • Direct connectはプライベトネットワークとVPCを高品質セキュアにつなぐサービス
  • 占有プランと共有プランがある
  • 質問があればネットワークベンダーに質問してみよう。

Q & A

Q1.

メンテナンスの頻度はよくある?

A1.

Direct Connectの推奨としては、冗長構成となっているので

片方がメンテナンスになってしまっても、

もう片方が残っていればいいというような状況にしておくのがよい。



2. AWS 専用線アクセス体験ラボトレーニング参加レポート

登壇者の方(濱田さん)から。

今回の講演で、面白かったポイントを伝えたりしようと思う。

また、これを聞いた人が参加したいなと思ってもらえたらよいかなと思う。

資料

 

以下、講演を聞きながらのメモ

イントロ

濱田さんが日頃の業務をしているときに

AWSとオンプレとの接続はマスト要件」という案件がある。

そういう場合は、

Configファイルを渡して、つながったら、よしやった!と思う。

ただ、当時のイメージとしては、

お客さん側の得体のしれない機材や得体の知らないネットワークが

どのように稼働しているのかイメージがつかなかったため、

体験ラボハンズオンに参加した。

 

結論からいうと、バックエンドやVPNとかよくわからないという方にとっては

とても学びがあって楽しい。

体験ラボとは?

学べる。

ルータを使った接続の体験とかができる。

会社でネットワークの運用とかをやっている人におすすめ。

 

トレーニングは2種類あって、

ハンズオントレーニングの方をやってきた。

(もう片方は座学なのかもしれない、、、たぶん。)

 

料金が無料!!!!!!!!

 

ハンズオン会場は、AWSのビルの素敵なところで行なう。

注意:ボルダリングするところがあるが、そこの写真とると怒られる。

 

行くときは、PCAWSアカウントを用意しておく。

 

講師は、AWSの菊池さんという人。ガチガチのスペシャリストの人。

とても丁寧に教えてもらえる。

 

ハンズオン形式でテキストを進めて行く形。

 

講演の中で説明されるが、

あるWEBサイトにAWSアカウトを登録すると

自分のAWSアカウントのDirect Connect のところに

Virtual Interfaceが自動で作られる。すごい。

 

ハンズオンの中では、VGWの作成などが

こうやればできますよってテキストに書いてあって、それをやる。

 

ある程度最初に、どんなことをやるのかイメージして

ハンズオンで進めていくことで理解が深まるのでよい。

よかったこと

  • Direct Connectの設定の流れを一気通貫で学ぶことができる。
  • ルーターコマンドを体験できる。
  • 講師にマニアックな質問ができる。
    → 参加人数がそれほど多くないので、
    ネットワークスペシャリストにVPNや専用線の質問ができる!
  • テストラボトレーニングの資料がもらえる。

まとめ

これまで霧のようなイメージだったお客さん側の環境が理解できるようになった!

また、無料だし3時間くらいだし、失うものは何もないので参加すると良い!

AWS 専用線体験」で検索!

Q & A

Q1.

無料ということだったが

ハンズオン内で行うAWS料金も無料?

A1.

そこはさすがに自分持ちです。

ただ、ハンズオン内でかかる費用は50円くらい。

しかも、ハンズオンの資料がもらえるので、それを見ながら1週間くらい遊んだりはできる。

1週間くらいはハンズオン用のデモの環境を残しておいてくれるので)



3. VPN接続とルーティングの基礎

まず始めに、登壇者の菊池さんから

今回はだいぶテクニカルな内容になります。と説明があった。

菊池さんは、AWS認定を8冠しているすごい方。

資料

 

以下、講演を聞きながらのメモ

1. AWSVPN接続

いわゆる、インターネットVPN

 → インターネット上の通信でパケットをカプセル化することで仮想敵なトンネルを形成

 

実現方法によって2つの分類がある。

  • ハードウェアVPN
  • ソフトウェアVPN

ハードウェアVPN

接続に必要な部分が、AWSのサービスとして提供されている。

ソフトウェアVPN

EC2の中にソフトウェアをインストールして、そこを通してVPN接続すること。

 

この2つを比べて一番違う部分が、

ソフトウェアVPNの場合は、

VPN接続の部分を、ユーザが自分たちで保守・運用しないといけない
例えばEC2インスタンス建てたりソフトウェアをインストールしたりとかということ

今回のテーマはハードウェアVPN

ハードウェアVPN = マネージドVPN

拠点間を繋ぐIPSecVPN

2. ハードウェアVPN

出てくるコンポーネントは3

  • customer gateway
    → オンプレ側に設置するルータ
    public ipを必要とする。
  • virtual private gateway
    VPCにアタッチするゲートウェイ
  • VPNトンネル
    → CGWとVPGを繋ぐ

 

AWS上での設定はとても楽。3ステップ。

 

設定ファイルが最後にDLできる

 

設定ファイルには、

  • IPSecVPNの設定情報
    → IKE/Ipsec/TUNNEL
  • BGPルーティングの設定(動的ルーティングの場合)

が書かれており、

IKEの事前共有鍵、AWS側の接続先IPなどが書かれている。

 

AWS側では、2箇所でルートが設定されている。

  • VGW
  • VPCのルートテーブル

3. BGPによる経路交換

AWSを使うと、IPSecまでの設計はほとんどいらない。DLするConfigに書かれている。

ネットワークの経験がない人がBGPをやろうとすると、一気にハードルが高くなる。

 

BGPとは?

Border Gateway Protocol

のこと。

動的ルーティングプロトコルの1

 

AS(Autonomous System:自律システム)間で経路情報を交換する。

ASナンバーというのは、大きなネットワークキャリアとかが、他と通信するための番号。

 

TCPで接続したルータ間で経路をアドバタイズ(広報)する

 → パスアトリビュート属性を付加することで経路を制御

  → ISPとかが複数の経路を提示してくれるが、
この属性によって最短の経路が何かを示してくれる。

 

VGWVPNトンネルの間にルータが2つある。

  • CGWで設定したCIDRCGWから受け取るルータ
  • VPNCIDRCGWに送信するルータ

 

BGPでは、パスアトリビュートのパラメータが10以上ある。

AWSでよく使われているのは

  • Local_Prefence
  • AS_PATH
  • Med

ここら辺の話はとてもディープな話になるので、

また次回の勉強会でやろうかな菊池さんがおっしゃってました。

4. 設定時の注意

CGWには実績のある機器を設定しよう

 → 不具合の回避

 → 実績のない機器を検討する場合は事前検証を。

 

AWSが公式に検証をサポートしている機器もある。

そういうものを使えば、まぁ、間違いないでしょう。

その機器の中に、 Cisco とか Juniper とかある。

コラム

ネットワーク屋さんからすると、CGWVGWは同じ機種を使うのがセオリーなので

AWSで使われている、謎の機器を使うときは、サポートされているものを使いましょう。

サンプルコンフィグの注意点

CGWNAT環境にある場合。

クライアントのFireWallの奥にCGWがある場合。

その時は、インターネットからFireWallを超えてCGWにアクセスできるように設定しよう。

サンプルコンフィグを使うと、NATGWIPが記載されているので、そこの書き換えが必要。

繋がらないときのトラブルシューティング

  • Ipsecがダウンしていないか
  • BGPがダウンしていないか
  • ルートテーブルが反映されているか

まとめ

  • ハードウェアVPNはマネージドなIpsecVPN
  • BGPまたはstaticルーティング経路を設定
  • AWSが、設定は簡単

Q & A

Q1

今回話したような内容は、ネットワークベンダーさんがやってくれる?

A1

基本的にやってくれる。

Q2.

経路交換しているときに、

VPC側の経路情報が流れてしまうという話があったがルーティングの設定をすればよいのか?

A2.

そうですね。オンプレの設定だけルーティングするような設定をしないといけない。

Q3.

Direct ConnnectSLAの設定がないという話で、冗長構成が推奨ということだったが、

どういう内容があるか?

A3.

データセンサーから線を2本引くなど。どこまでお金かけるかとか、考え方とかによることになる。

Q4.

AWS側でVPN接続する際にルータが2

CGWCIDRを受け取るものと、VPCCIDRを送るもの)出てくるが、

それが別れているのはなぜか?

A4.

AWS側が冗長化のためにやっている。

メンテナンスの際は、片方がとまるが、片方は生き残ったままというような形になる。

【CDN Study (Akamai/Fastly)】に行ってきました

CDN Study (Akamai/Fastly)

https://http2study.connpass.com/event/81469/

に行ってきたので、そのときのレポート

イントロ

資料

まず、jxckさんから

CDNの変遷(変化)

edgeの数こそ正義

そのあと

edgeの数よりは同じurl使ってることが良いよねってなった

jqueryのダウンロードを他のサイトでやってたらキャッシュされるよねとか

さらに

cloud cdnが出てきて敷居が下がった。

ただのファイルだけじゃなくて、

imageを最適化してくれるとか

ddosに強いとか

さらにedgeの中でいろんなプログラムが動いてたらいいよねとか

cdnが前提になりつつある今

パフォーマンスやセキュリティの面から

edgeが正義という感じではなくなってきた。

縁の下の力持ちという感じではなく、

もっと前へ前へと出てきている感じがする。


Akamaiの方(岡本さん)の話

悪魔で個人(登壇してくださった方)の見解です

資料

CDNの過去と現在

各CDNベンダの歴史を見てみる。

一応、CDNですと言って出てきたのは1995年にAkamaiが初

そのころ、今のインターネットはコンテンツ配信が中央集権的なものになってしまって

限界があるだろうと言われていた。

 

http://as2914.net/

というサイトで、インターネットの地図が見れる。

すごい

このサイトからも分かるように、インターネットはとても複雑な網目状になっているのに対して

配信箇所が一箇所だと、渋滞が起きてしまうだろう。

 

1998年にstar warsの映画の予告編が公開された

これが、「インターネット最大のダウンロードイベントだった」と、スティーブジョブズが言っていたらしい

このように、コンテンツが一気に様々なところからDLされるということがあり

このままではインターネットは壊れてしまうと予想された。

世界で動画を配信するような設計に、インターネットはなっていなかった。

このようなことからCDNの必要性が出てきた。

CDNの基本的な考え方

ユーザーの近くに必要なファイルのコピーがあればよいではないか。

akmaiの仕組み(ほんの一部)

Akamaipop(edge)が他のCDNベンダーと比べてダントツで多い(桁が1桁違う)

世界中に数多くあるのがAkamaiの特徴

ただ、数が多いと大変という話

ユーザーをどうやって最適なedgeに誘導するのか

 → DNSの名前解決の時点でアクセス元によって応答を動的に変える

  → 実は、これはAkamaiの特許(2019年で特許が切れる。)

Google Public DNSとAkamaiが相性が悪いという話

 → 全てが8.8.8.8からきてしまうと、区別がつかない

  → 今は別に相性が悪くなくなっている

最適なエッジサーバー群とは?

CPUバウンドやネットワークバウンドなどいろいろな要因があるなかで最適なedgeを探すのは難しい

 → 安定結婚問題、gale-shapleyアルゴリズムを当てはめている

Akamaiedgeサーバーの構成

  • 高機能な独自開発httpサーバー
  • xmlベースのdlsでロジックを組む
  • 膨大な機能があるため、したいことは現場のエンジニアレベルで大抵できる
    → なので、この問題はUSに問い合わせないとということがあまりない。

せっかく近くにいるのだから、もっと高度な処理をしたいよね

例えば、セキュリティ対策など

岡本さんがCDNでしたかったこと、していること

  • ddos対策
  • waf
  • スクレイピング対策
  • 画像動画htmlなどを自動的最適化
  • webサイト全体
  • apiをキャッシュから出して応答を速く
  • 静的ファイル配信はまかせたい
  • sslセッション数が多すぎるので対処
  • インターネットの経路の不安定さを解決

CDNのもともとの名前の意味としても

現状は大分変わってきている

Akamaiの動き

bot managerimage managerをリリース

最近だと、2018年にedgeで動作するjavascriptを開発中。

Akamaiの方(塲田(ばだ)さん)の話

資料

Akamai も標準化へ参加している

CDNがどんどん進化していくのも必要だし、ブラウザもどんどん進化する必要がある。

CDNベンダーもブラウザと共通言語で話せる必要がある。

新しいプロトコルを使いたいとなった場合もブラウザの対応が必要になる。

Akamaiによるhttp2

ユーザからhttp2でリクエストをしてもらい、Akamaiで受け、http1.1webサーバーに流すなど

real user monitorRUM

 → このページを見たユーザはこのページも見そうだから、
このcssjsを送るようにしよう
というアルゴリズムを作ったりしている。

QUIC

https://blogs.akamai.com/jp/2017/05/udpquic—akamai-media-acceleration.html

TLS1.3

draft21もしくは23に対応したopensslを使えば、AkamaiとTLS1.3で通信ができる

CDNの未来

edgeはどこか?
→ 今後、もっとedgeがユーザの近くになるのではないか
携帯電話会社なのか、電柱なのか、スマホの中なのかとかとか

edge computing がくるぜ!っていう論文もある。

The Emergence of Edge Computing
http://elijah.cs.cmu.edu/DOCS/satya-edge2016.pdf

  • コンテンツ予測配信
  • 携帯電話専用回線網
  • デバイス間コンテンツ共有
  • などなど、、、

webガバナンス強化のためのCDN

様々なドメインでサービス配信してる時に、メインサービスは脆弱性対応しているが、全てのサービスに手が回ってないとか

自分の会社のサービスはどこが守れていてどこが守れていないのか

どこがcipher suite しているのかしていないのか

そういうことを管理できるようにしよう。

取り入れられそうなこと

開発後にチューニングとしてCDNを取り入れるのではなく

CDNを最初から考え、どの程度のTTLなら許容できるのか、キャッシュはどのようにしようかなど設計しましょう。

cacheabilityの観点からのアプリケーションのモデリングをしよう

  • キャッシュの時間設定などが、ボトムアップだったり、良い設計ができていなかったりする
  • キャッシュの生存時間を変更できるようなアプリケーション

Let’s Encrypt

Akamaiを使えば、Let’s Encryptとの連携も比較的簡単にできるよ!

 → Let’s Encryptをそのまま使うとなると、 cert bot などちょっと癖があるが、
そういうのを簡単にできたりするよ。

Q & A

Q1.

cacheabilityに関して、

それを取り入れるのが難しいと思うが、

webアプリケーションフレームワークの中にcacheの機構を持たせるようなことができたらハードルが下がりそうではないか?

A1.

たしかに、その視点はなかったが、それは良さそう。

Q2.(岡田さんから)

Multi CDN の話とかがあるが

A2.

あんまり凝ったことをしたいわけではないのなら、singleでやったほうがいいと思う。

Q3.

server pushってクライアント側の情報がわからないと難しいと思います。

cacheダイジェストなどもあるが、Akamaiさんの中でどのくらいserver push が使われていて、どのくらい早いのかとか教えてほしい。

A3.

アルゴリズムの際に、機械学習などを利用しているという風に、岡田さんは聞いている。


Fastlyの方(奥さん)の話

悪魔で個人(登壇してくださった方)の見解です

資料

Fastlypop設計

キャッシュヒット率を高めたい。

  • コンビニモデル
    → ユーザの近くにたくさんのpop
     → メリット:底レイテンシ
  • スーパーマーケットモデル
    → ixの近くに巨大なpop
     → メリット:cacheのヒット率をあげることができる。

Fastlyは主にスーパーマーケットモデルを採用している。

popのキャパ

1Tbpsクラスのネットワーク

32台のクラスタ

Fastlyはルータレス、ルータを使っていませんよ。

32台のサーバーがルータも兼ねている

ロードバランサ

大量のリクエストをさばくにはコストが高い。

ECMPという技術

 → これも問題がある

  → 外すタイミング問題

   → ステートレスロードバランサというやり方をしている

    → クラスタの応用、ノードにあるサーバが知っている通信は別のサーバに流さないし、知っていない通信は別のサーバに流す。

他社と比べて

http2も早い

まとめ

FastlyはAkamaiとは違い、スーパーマーケットモデル
 → そのために、スケールアップ・スケールアウトの仕組みをソフトウェアを使って実装している

VCLについて

VCLができること

  • リクエストのルーティン具
  • リクエストの書き換え
  • レスポンスヘッダの書き換え
  • リクエストの再送(回数制限あり)
  • etc…

パージ

  • URLを指定してパージできる
  • キーを指定してのパージ
    → 特定のキーがついたキャッシュをまとめてパージできる
    → 例えば、jscssのファイルを一気にパージしたいとき、特定のキーを持たせておいて、それをパージさせる
    → メリット:url単位での参照、パージができる

ヒット率の高いキャッシュ率を実現するには

  • 大容量のキャッシュ
  • インスタント・パージ
  • shielding

他には

  • waf(web application firewall)
  • ddos対策
    → ddos対策をしながらも、他のお客さんにも迷惑がかからないような仕組み
  • edge-side includes(Akamaiでもやっているし、Akamaiからの移行もしやすそう)

CDNの歴史とこれから

  • プロトコル上の制限がボトルネックに
  • スマホの普及
  • スノーデン事件
    → 大規模な情報を管理する上で、プライバシー保護について厳しくなった

このようなことから、インターネットとプロトコルが進化してきた。

プロトコルの進化の方向性

  • 全ての通信の暗号化
    → ルータとかでの通信の硬直化をしないようにしよう
  • 迅速なセットアップ
    → リンクを端末にpushし、それがブラウザ上にあるか確認したりする
  • ネットワークをまたいでも途切れない通信
  • 劣悪な環境でも粘り強く通信をするように
  • DNS over https
    → DNSからのクエリなのか、CDNからのクエリなのか分からなくなるので、セキュア
  • cache diggest http
    → オリジンの処理中にCDNからアセットを配信
  • server timing
    → 配信タイミングをjsで取得
  • secondary certificates
    → 1本のTLS接続で複数の証明書を使う
  • short term cert
    → ある国では、証明書は政府で管理しましょうとなっているところもある。
    できるだけ秘密鍵が漏れたときの影響を少なくしよう。
  • variants
    → varyのキャッシュ爆発の問題を対策

QUICの目標

  • 1個目のパケットが処理できなかったとしても、2つ目3つ目のパケットを処理できるようにしたい。
  • 進化を続ける通信プロトコル
    → tcp first open という機能は、8年間実装にかかったりした。
    それは、アップデートを邪魔をするルータがいたりしたため。
    → アップデートに妨げられないプロトコルが必要
  • 相互接続試験をやりながら、各社プロトコルを実装している。
    → googleはGquicというものを使っているが、だんだんIquicというものに近づけている。
    そのような動きもある。
  • Fastlyもプロトコル標準化に参加している

まとめ

CDNとしてのミッション

  • より安く、より速くコンテンツを配信
  • 全世界的な分散kvs
  • edge cloud
  • プロトコル進化の促進

Q & A

Q1.

web packagingについてどう思いますか

A1.

ampの問題などがあるが、web packagingのような技術が標準化されるのはいいと思う。

Q2.

ネットワーク回線も問題になりがち。配線や回線について工夫しているところはあるか?

A2.

私はsoftware engineerなので言えることは少ないが、

弊社はコンテンツ配信の一点特化なので、それに合わせた設計をしている。

例えば、ルータレスルーティングとか。

Q3.

Fastlyvarnishが元になっていたりして、edgeのほうにバグが発生することも考えられるが

そのようなものに対してテストをやるための仕組みはあるか?

A3.

お客さんがテストするような仕組みはちょっと分からないです。開発の中でもテストはあると思うが。

ちょっと他の人に聞いてほしいです。すみません。

Q4.

標準化の中でデータを公開する話とかどうなってますか。

A4.

そこがやはり議論になっていて、何を見せて何を見せないかっていうのをちゃんと考えている。

例えば、うっかりルータから見えてはいけない情報が見えたりとか。

なので、何を見せるのか、見せない代わりに何か別のものを見せるとか、そういうのを明文化している。

Q5.

CDNwafとかddosの話も出ている。

ただ、動的なコンテンツを配信しているwebサーバもあり、どこまでを通すのかというのが難しいと思う。

どこが適材適所なのかという意見とかあるか。

A5.

FastlyはCDN会社なのでCDNでやってほしいと思うが、どうしても共用サーバであることの制約とかもある。

どうしても処理の重いこととかは、別なサーバーでやったほうがいいなどトレードオフはあると思う。

【ネットワーク技術者ではない方々向けIPv6セミナー2】に行ってきました

【ネットワーク技術者ではない方々向けIPv6セミナー2】

https://connpass.com/event/69423/

に行ってきたので、そのときの雑多なメモ

IPv6最新動向 ~世界共通語で最適化が進むインターネット~

資料

メモ

英語に例えると、

何かを(翻訳とか)介して人は対話をする

ipに関して,

3つの波があると思っている。

今日は、世の中のクラウドかによって、v6化が進んでいるという話をする。

v4は、いまだとオークションで売られたりもしている

/18

というのが、2千万円とかでやりとりされてたりもする。

/16

いまでは、1億円前後

海外におけるv6

googleには、20%くらいv6アクセス

日本からは18%くらい。

平均値くらい。

アメリカのモバイル回線の話

アメリカはすごい

アメリカの事業者は進んでいる。

appleのような先進的な会社で、v6を押している

AWSv6対応している。

などなど、そのように対応している会社はたくさんある。(買いてたらキリがない)

MSasurev6対応

MSは車内はv6対応している。

なぜか?ソースのURLがあるので、それを見てもらったらいい。

Dual stack はニーズに合わない。

そんな時代になっているという紹介。

facebookのような大きな会社も、ほぼv6対応している。

すごい。

load balancerが通訳の役割。

世の中的に、v6が世間一般になったら、この翻訳(load balancer)の部分がいらなくなるという仕組みになっていると読める。

IETFでもv6で行くぞという流れになっている。

RFCでも新しいドキュメントになった。

世界の流れという意味でも、このような流れがある。

V6は危ない?

globalからglobalなので危険?

フィルタの昨日があるので、

v6が危ないのであればv4も危ないという同等の考え方ができる。

NATテーブルに足跡が残る。

海外に置けるV4の話

サービスとかコンテンツって何か?

簡単にいうと、v6の中にv4を入れれば、v4はv6のコンテンツになる。という考え方。

経路数が増加しているので

みんなのルータをリプレイスリプレイスしないといけなくなる。

ipv4ipv6の足し算

ipv4ass

の考え方、一部のルータだけが頑張ればいいようにする。

他は安っちいルータでいいようにする。

(ここまでのまとめ)

  • 世の中のマップがこのようになっていると思える。
  • 端末は、v4のものを探すのが大変なような世の中になる。
  • 大手コンテンツ業者がv6をやろうとしていて、NW事業者もv6対応をやろうとしていて、上から下まで全部がv6のような世の中になろうとしている。

国内のv6の話

長い黎明期があったが、2011年からv6対応になってきた。

それでもしばらくかかっているほう。

46スライド

このようなやり方で、v6の普及率がバーンと上がった。

56スライド

9月の時点では40%超えてるんじゃないかなぁという予想

現在のVNE社の数は7

64スライド

V4の共有が始まっている。

この問題は

日本ですぐに直結するわけではない。

家庭&小規模オフィスのブロードバンドとIPv6

資料

メモ

家庭で導入するには何が必要?

契約さえすれば、v6対応はできる。

フレッツ光・光コラボサービスが、いろいろと癖があるらしいので、それの話をする。

光コラボというのはフレッツがやっているわけではない。

プロバイダーがやっている。

14スライド

契約の違いが、我々(みなさん)がv6したいときにあとあと尾をひいてくるところ


v6ってインターネットが早くなる?

もちろん誤解だけど、なぜそういう話がでてきたのかの話をする。

ipv6を使えば早くなるということの説明の1つが

IPoEの話がある。

IPoEだと、もう終端装置を使わない。

結局もう終端装置が混雑しているので、そこを経由しないので早くなる。

26スライド

日本のインターネットは遅いままなのか?

というのに対しての打ち手が

IPv4 over IPv6