このページの本文へ

JAWS-UG首都圏勉強会レポート 第10回

AWSとネットワークをディープに語る勉強会開催

キャリアを超えてネットワークを語り合うNW-JAWSが始動!

2017年01月06日 07時00分更新

文● 重森大

  • この記事をはてなブックマークに追加
  • 本文印刷

時間は短いが濃いLTが6本! 1本目から具体的な通信料が語られる

 LTは希望者多数により6枠設けられた。1枠約5分だが、いずれも実際の現場からの生々しい話が詰まった濃い内容ばかり。普段のJAWS-UGなら普通の1セッション分語れるのではないかと思うような話もあった。

 1番バッターは、NTTドコモの森谷 優貴さん。「どんな会かわからず資料を作ってきたが、思ったより固い会だった」と感想を漏らしてからの、LTスタート。話題はAWSのネットワークコストの話だ。

「クラウドサービスの中には通信料が無料のものもあるので、AWSの通信料は、一見すると高く見えます。では実際どれくらいかかるのかってことを話したいと思います」(森谷さん)

NTTドコモ 森谷 優貴さん

 ドコモでは250アカウント、EC2が4000台以上、S3も10PB以上使っているとのこと。それらをサービスの種類ごとに分け、2016年8月から10月までの月間平均値を計算したという。具体的な金額は言えないので、サービスコストに占める割合で示されたが、かなりわかりやすい資料となっていた。

NTTドコモの各種サービスに占める通信料の割合

「パーセンテージではなく、具体的にいくらなんだ?って思っている方に、一例だけご紹介します。データ分析系のハイブリッド環境でダイレクトコネクトを引いて、300TBくらい転送して、S3もPB級で使っているあるサービスでは、月間の転送料は400ドル程度です。僕のポケットマネーでは無理だけど、ハンズラボの長谷川さんなら払える程度ですね(笑)」(森谷さん)

 AWSの転送料は一見高く見えるが、サービスコスト全体で見ると実はそれほど高くはないと森谷さんは言う。そして最後にこうまとめた。

「AWSの転送料は1GB当たり約14円です。ドコモのスマートフォンの1GBの通信料は……ということで、どちらもご利用は計画的に」(森谷さん)

 ちなみに、次のLTまでの合間にハンズラボの長谷川さんがECサイトでの通信料について語ってくれた。

「小売業仲間からよく相談されるんですが、小売業でECサイトをやる場合、8割から9割はEC2のコストになります。なので、EC2の金額を試算して、それに5%から10%上乗せして見積もっておけばいいのではないかと答えています」(長谷川さん)

2本目、3本目はネットワーク機器の具体的な使い方に踏み込む

 2番手に立ったのは、マクニカネットワークスの山下 浩平さん。マクニカネットワークスは多くの企業ニーズに応えてきているため、日本のネットワークがどのように使われているかというダイレクトな声を聞いているという。2014年くらいから顕著なのは、グローバル化とクラウド化。その中でもAWSに特化した部分だけを今回は取り上げてきた。

「AWSとの接続で課題となるのは、セキュリティを保ちたいということ。本社からダイレクトコネクトを引いてあるので、すべてそこを通すというのがよく使われる手法ですが、これでは通信帯域の限界が来ます」(山下さん)

マクニカネットワークス 山下 浩平さん

 そこで提案しているのが、各拠点から直接AWSに接続する方法。具体的にはクラウド上にソフトウェアベースのルーターを置き、各拠点とIPsecで結ぶ方法。しかも、拠点同士も通信できるようにフルメッシュで結ぶという。とはいえ、これはネットワークに詳しい人はうんざりする話ではないだろうか。

「以前は25台程度のフルメッシュを設定するのに1年くらいかかっていました。しかしviptelaというSD-WAN(Software Defined WAN)製品を使うと、1000台のフルメッシュでも5分くらいで自動設定してくれるんです。なんだ宣伝かよって言わないでください、本当に便利なんでどうしてもこれだけはお伝えしたいんです」(山下さん)

 ということでSD-WAN製品の宣伝だった訳だが、1000拠点のIPsecフルメッシュ接続を数分で設定できるのは確かにすごい。しかもダイレクトコネクトなど他回線との併用が可能で、自動的に適したネットワークを選んで通信してくれるのだという。

「現在の課題は、AWS上でルーターを二重化できないということです。もしうまくやっている人がいればぜひ教えてください」(山下さん)

 製品販売側のLTに続いて登場したのは、ネットワーク機器のユーザー側であるcloudpack(アイレット)の山本 友さん。社内で使っているジュニパーのファイアウォール製品SRXシリーズを使っていて直面した課題とその解決策について語ってくれた。

cloudpack 山本 友さん

 cloudpackを提供するアイレット社内ではジュニパーネットワークスのファイアウォール製品SRX100シリーズ、SRX200シリーズを使っていたが、販売終了によりSRX300シリーズにリプレースした。その際、SRX100、SRX200シリーズで使っていた設定をそのまま読み込ませたところ、いくつかの不具合が生じたという。

「1つめの問題は、DHCPサーバーがMacOSに対応しないことでした。これは、ジュニパーの機能であるJDHCPを使うことで解決できました。2つめの問題は、サブインターフェースの設定が機能しないこと。設定自体は読み込めるのですが、想定通りにVLANが割り当てられなかったのです」(山本さん)

 ここで山本さんは実際のコンフィグを公開。ネットワークインターフェースにVLAN ID2を割り当てるよう指定されているが、実際には動かないのだという。この問題は手順を逆にして、まずVLANを定義し、そのVLANにネットワークインターフェースを割り当てるようコンフィグを変更。これにより当初の想定通りにネットワークが機能するようになった。

動作しなかった、問題のコンフィグ

「3つめの問題は、NAT環境下でSRX300同士のIPsec接続ができないこと。これはいろいろと検証した結果、ジュニパー製品側のバグと判明しました。12月末にリリース予定のバージョンアップで修正予定だそうです。現在は、接続先SRX300の物理インターフェイスを指定することでこの問題を回避しています」(山本さん)

 筆者は以前エンタープライズ向けネットワーク製品の広告を多く取り扱っていたので、これらの製品や機能についての説明が懐かしく響いた。プラグをカシメて機器につなげてランプが点くと喜ぶというほどではないが、データセンターのラックにひしめくエンタープライズ向けネットワーク機器で酒が飲める程度に、エンプラITフェチではある。そういう意味でも楽しいLTだった。

カテゴリートップへ

この連載の記事