ネットワーク技術者ではない方々向けIPv6セミナー2:Geekなぺーじ
6月に開催したネットワークエンジニアではない方々向けのIPv6勉強会に続き、10月18日(水)に第2弾を行います。 ネットワークエンジニアではない方々向けのIPv6セミナー2 前回の話 6月のときのブログは、以下の2つです。 ネットワークエンジニアではない方々向けのIPv6勉強会します ネットワークエンジニアではない方々向けIPv6勉強会を開催しました 前回の私の発表資料は、次のような内容でした。 全体的に「IPv6とは何か」とか「IPv6とIPv4によるデュアルスタック環境とは」などの話が中心でした。 第2回企画の経緯 第一回最後の質疑応答時間で、「では、実際に始めるには何をどうすれば良いの？」といった感じの質問が出ていました。 中には、フレッツにおけるIPv6の質問もありました。 ということで、今回は実際に現場で活躍されている方々による発表という方向性で勉強会(セミナー)を企画しました
「女性は生まれつきエンジニアに向かない」と元Google社員は主張していたのか？:Geekなぺーじ
Google社員が「女性は生まれつきエンジニアに向かない」という社内文書を作成したというニュースが話題になっています。 ITMedia: Google、中の人の「女性は生まれつきエンジニアに向かない」文書回覧で社内騒然 そこには、以下のように書かれています。 ダイバーシティ重視を打ち出しているのにエンジニアの女性比率がなかなか上がらないGoogleさん。男性エンジニアが「だって女性はエンジニアに向いてないんだよ」という社内文書を公開して大騒ぎ。 この騒動は世界的なニュースとなり、社内文書を作成したGoogle社員は解雇されました。 BBC: グーグル、「男女は生来能力が違う」と書いた従業員を解雇 BBCの記事には、以下のように書かれています。 ピチャイ氏は、グーグル社内で表現の自由を守る重要性について行数を割き、「文書に書かれた内容の多くは、議論に値するものだった。グーグル人の大半が賛成す
「ひとりで何でもできるエンジニア」は勝手に育つ:Geekなぺーじ
「スタートアップベンチャーはスーパーエンジニアを求めるけどエンジニア界隈と起業家界隈で想像しているスーパーエンジニアの定義が違う件」という記事が話題です。 その中で、「「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」」として、以下のように書かれています。 「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」 起業家の方が知らない側面として 現在バリバリ活躍しているエンジニアのほとんどが得意領域を持っていて それ以外の分野については出来る人であっても「平均点以上」ぐらいの活躍しか出来ないということです。 そして優秀なエンジニアの方はそのことをよくわかっています。 たまに化け物みたいな化け物がいて物理からインフラからアプリケーションからUI/UX ネイティブアプリ開発からwebマーケティングに資産管理まで全部出来ちゃう人もいますが その人を望む事は「年収1000万の
「ひとりで何でもできるエンジニア」と時代背景:Geekなぺーじ
インターネットそのものが「新しいもの」であったころは、インターネットそのものとともにITエンジニアが成長できました。未踏な領域に踏み込む冒険心をくすぐられるミッションが、そこら中に転がっていました。「できなくてツラい」と苦しみつつも、マゾ的に心を踊らせチャレンジする環境がありました。 インターネットを利用することが珍しいことではなくなり、インターネットを活用したビジネスを実現するためのエンジニアリングの分業化も進みました。それに伴い、IT系エンジニアに求められる技能が細分化しており、「必要に応じて全部やる」ことが求められない環境も非常に多くなっています。 そういった環境の変化もあり、「昔と違って何でもできる人は育ちにくくなっている」という感想を持っている人も結構多い印象です。私の周りで「ひとりで何でもできるんじゃないかと思えるほど守備範囲が広いエンジニア」と私が思う凄い人々は、インターネッ
Real World HTTPはスゴ本:Geekなぺーじ
Real World HTTPの献本ありがとうございます。Webトラフィックを運ぶプロトコルとして利用されているHTTPの解説書として、HTTP 1.0、HTTP 1.1、HTTP 2.0のプロトコルだけではなく、ブラウザやサーバが何を行っているのかを含めて解説しています。 Real World HTTPの凄いところは、過去の経緯をふまえつつ、HTTPという軸で実際に使われている部分とそうでない部分を明確にしつつ解説されている点です。 しかも、範囲は非常に広いです。HTTPと関連する話として、たとえば、TLS、WebRTC、RSS、RDF、OGP、JSON、GeoLocation、RESTful APIなども解説されていますし、勘違いが発生しやすいno-cacheやno-storeなどに関しても解説されています。 すべての項目に関して詳細に解説されているわけではないものの、それぞれかなりし
ネットワークエンジニアではない方々向けIPv6勉強会を開催しました:Geekなぺーじ
昨日、ネットワークエンジニアではない方々向けのIPv6勉強会を行ってきました。 会場をご提供いただいた株式会社インターネットイニシアティブ様、ありがとうございました！ 発表資料をSpeaker Deckで公開しました。 当日の参加者は約150名でした。一部、私よりも詳しいネットワークエンジニアも参加していましたが、全くIPv6に関しての前提知識がないと思われる方々や、自分でIPv6 IPoEを設定してみたというかた、これから実際に手を動かしてみたいというかた、仕事でこれから必要になりそうなので調べ始めたというかたなど、様々な方々が参加されていたようです。 「ネットワークエンジニアではない方々向け」という内容ではあるものの、「どういう説明をするのか見てみたい」というネットワークエンジニアの方々もいたことや、見たことがあるTwitterアイコンなどがconnpassに表示されていたので、顔見知
BBIX BGP Meeting:Geekなぺーじ
2017年6月16日にBBIX BGP Meetingが行なわれました。先日書いたTwitterの記事とSpotifyの記事も、BBIX BGP Meetingで発表された内容を記事にしたものです。 BBIXの福智氏によると、BBIX BGP Meetingの「BGP」は、Borderless Group of Peeringの略であって、Border Gateway Protocolの略ではないとのことでした。同社の目指す「No Peering, No Internet」を体現するための取り組みのひとつで、一般的ないわゆる「ユーザ会」とは違う方向性を目指しているそうです。 BBIXに接続しているAS数は、約160、トータルトラフィックは約830Gbpsに登るという現状も紹介されていました。 BBIX BGP Meetingのアジェンダは、「勝手にプログラム委員会」という有志が作っています
LINEも「ギガが減る」を観測していた:Geekなぺーじ
今年1月に開催されたJANOG 39にて、LINE Corporationの三枝氏が「LINEサービスを運用して見えてきた課題」というタイトルで発表を行っています。 その中で、「月間平均Response Timeとの乖離」というタイトルで、以下のスライドがあります。 この図では、日本、タイ、台湾のレスポンスタイムが示されていますが、「日本は月末にResponse Timeが悪化していく傾向がある」とされています。 Twitter、Spotify、JPNAP(インターネットマルチフィード)での「ギガが減る」を昨日から紹介していますが、LINEでも同様の現象を観測しています。 やはり日本のインターネットトラフィックの最近のトレンドとして、月末に向けて通信品質が悪化するという傾向があるようです。 参考 Twitter Loves Japan Spotifyの日本インフラ 日本のインターネットも月
日本のインターネットも月末に向けて「ギガが減る」:Geekなぺーじ
一部界隈で「ギガが減る」という表現が話題です(参考:若者はみんな使っている？謎のワード「ギガが減る」とは)。 「ギガがない」「ギガが回復した」「ギガが限界」「ギガがやばい」といった表現をTwitterなどで発見することもできます。データの単位を示すギガバイトのうちの「ギガ」という部分が何故か物のように表現されており、なかなか破壊力が大きい衝撃的なパワーワードです。 最近話題になっているのは「ITに詳しくない人々が使う変な表現」という面白ワードとしてですが、そういった表現が、実は日本のインターネットトラフィックの傾向を示すものになりつつあると言えてしまうのかも知れません。 IX事業者が見る「ギガが減る」 インターネットマルチフィード株式会社の吉田氏が2016年のIP Meetingで発表した「2015年インターネット運用動向」(PDF)の中で、次のように月初めから月末にかけてトラフィックが落
Spotifyの日本インフラ:Geekなぺーじ
BBIX BGP Meetingにて、SpotifyのPeter Carlsten氏がSpotifyの日本進出について発表しました。 おそらく偶然だとは思いますが、同じイベントの別セッションで発表されたTwitterと同様に巷で話題の「ギガが減る」という状況を示すユーザトラフィックが公表されつつ、日本の通信事業者に対するピアリングの呼びかけが行われました。 日本ユーザの通信品質 Spotifyは、音楽のストリーミングサービスです。ユーザは、音楽を再生するためにSpotifyから音楽データをダウンロードしますが、Spotifyとユーザの間での通信品質が低いと、ユーザ側で行われている音楽の再生が途中でストップしてしまい、バッファリングが行われます。 SpotifyのPeter Carlsten氏は、バッファリングが開始されて音楽再生が引っかかってしまう状況を「stutter(どもり)」と表現し
Twitter Loves Japan:Geekなぺーじ
BBIX BGP Meeting 2017 Summerにて、TwitterのTim Hoffman氏が「Twitter loves Japan」という発表を行いました。 そこでは、Twitterの行っている独自CDNの紹介、日本におけるユーザトラフィックの特徴などが紹介などもされていました。発表そのものは、日本国内のASに対してBGPでのピアリングを呼びかけるというものです。 一部ネット界隈では「ギガが減る」という表現がホットな話題ですが、BBIX BGP meetingにおけるTwitter社とSpotify社による発表されたユーザトラフィックにおいても、そういった状況が示されているのが個人的には興味深かったです。Spotify日本進出の発表に関しては別途記事を書く予定です。 日本はTwitterを非常に多く使っている Tim Hoffman氏によると、Twitterでは、日本が最も大
ネットワークエンジニアではない方々向けのIPv6勉強会します:Geekなぺーじ
IPv6という単語は聞いたことがあるけど内容は良くわからない、自分に関係があるのかどうかよく分からない、近い将来自分に関係がありそうだけど何から勉強して良いかわからない、そういった方々向けに参加無料のIPv6勉強会(方向性としてはセミナーかもです)を2017年6月26(月)19:00に開催します。 10年以上前からいつまでたっても普及しない印象があるかもしれないIPv6ですが、その利用者は確実に増えています。日本でも、2017年度中に、スマホなどで利用されるモバイル網でのIPv6対応が本格的にスタートします(参考)。 IPv4で普及したインターネットでは、いまでもIPv4のほうがIPv6より多く利用されていますが、今後はIPv4とIPv6の両方に対応した環境が求められることも増えてくるでしょう。ユーザとして、サーバ管理者として、プログラマとしてなど、今後はIPv6の知識が必要になることもあ
「教える」こと、「学ぶ」こと:Geekなぺーじ
最近、「教える」とか「教わる」というのは、どういうことなんだろうと考えることがあります。自分ではない誰かに何かを「教える」というのは非常に難しいし、「教えたい」とか「伝えたい」と思うことは自分勝手であり、最終的には教わる側に主体性があって「教えて欲しい」という内容に沿ったものをどれだけ提供できるのかなのかなぁというのが最近の感想です。 新しいことを学ぼうとするとき、最終的には「自分で発見」をしないと覚えないし身につかないという感想を持っています。たとえば、授業のような形式でひとりの講師が多くの聴衆に対して講義を行っているような場合でも、その講義のなかから聴衆側が各自で小さな「自分の発見」をしていて、そういった「自分の発見」が「教わる」ということなのかなと。 最近は、スポーツ関連の勉強をしつつ、自分自身でも少しずつトレーニングを開始しています。40過ぎですが。 プロのトレーナーの方々向けの媒
AWSの計算力とストレージを使うクラウドセキュリティ製品 ProtectWise:Geekなぺーじ
Interop Tokyo 2017で、セキュリティ製品のShowNetコントリビューションとして、ProtectWiseが展示されていました(PARONGOブースは6S21のSecurity Worldパビリオン内)。 ProtectWiseは、リアルタイムな解析を行いつつ、通信データの長期記録による遡っての侵入検知などができる製品です。 ハードウェアによるアプライアンスではなく、AWSを活用したクラウド型であるため、通信データの記録を行うための巨大なストレージを動的に確保したり、必要に応じて非常に強力なコンピューティングリソースを投入したリアルタイムな解析が行えるのが大きな特徴だそうです。 ProtectWiseは、ネットワークに設置したパケット収集装置を経由してAWSに対して、通信データを送付します。 AWSのコンピュータリソースを活用したリアルタイムな解析事例としては、米国のアメフ
2017 ShowNetのサービスチェイニング【Interop Tokyo 2017】:Geekなぺーじ
今年のInterop Tokyo ShowNetの大きなポイントのひとつがサービスチェイニングです。 昨年のShowNetでも、サービスチェイニングが行われていますが、昨年のデモでは一部の限定したトラフィックをSDN/NFVエリアへと誘導するというトライアル的な内容でした。 今年のサービスチェイニングは、出展社に対するネットワークサービスとして運用されるという点が非常に大きな違いです。 昨年のサービスチェイニングは、指定したトラフィックをSDN/NFVエリアへと誘導するのにBGP Flowspecが使われ、SDN/NFVエリア内でのサービスチェイニングで提供するネットワークサービスの切り替えはOpenFlowが使われていました。今年は、トンネリングとBGP Flowspecの組み合わせによるサービスチェイニングが行われます。昨年はSDN/NFVエリアへのトラフィック誘導にBGP Flows
Interop Tokyo ShowNet 2017のサービスチェイニング:Geekなぺーじ
今年もInterop Tokyoが近づいてきました。会場ネットワーク構築のボランティアスタッフとして初参加したのが、ちょうど20年前ですが、今年は記者として10回目のInterop Tokyo取材になりそうです。 例年、会期中だけでは理解するのに時間が圧倒的に足りないのがShowNetです。ということで、今年は事前にShowNetで展示される内容に関して現段階で公開可能な情報を先取りで聞いてきました！ 当初、「今年のShowNetは例年よりも理解しにくいかも」と言われましたが、説明を聞いてみると、なぜそうしたのかに関する「心」の部分を教えてもらえれば構成としては非常にわかりやすいのではないかもと思いました。 そして、ここ数年の集大成となる未来のネットワーク像になりそうな気もしました。 Interop Tokyo 2017 ShowNet サービスチェイニング(Service Chainin
無償で読めるIPv6本を作ります:Geekなぺーじ
IPv6そのものは、決して新しいものではありません。 IPv6の最初の基本仕様であるRFC 1883は1995年に発行されており、そのRFCに関連する議論は、それよりももっと前から開始されています。 IPv4アドレスの在庫が枯渇することは、かなり昔から予想されていて、その対策としてIPv6が作られたのですが、IPv4とIPv6には互換性がないこともあり、IPv6が普及せずにIPv4のみが利用され続ける状況が長く続いたのです。 しかし、2011年にIPv4アドレスの中央在庫が枯渇したことによってIPv6が注目されるようになり、IPv6によるインターネットも急激に拡大していきました。 2011年当時の段階では、世界中のインターネットユーザが利用しているインターネットプロトコルはIPv4でしたが、2017年の段階ではIPv6普及率が50％を超える地域も登場しています。 Apple社が、2016年
【書籍】プロフェッショナルSSL/TLS:Geekなぺーじ
一昨年、「インターネットのカタチ」や「マスタリングTCP/IP」を手がけた編集者の鹿野さんが、オーム社を退職して技術書を扱う、ラムダノート株式会社という出版社を起業しました。 鹿野さんの会社が発売する最初の書籍である「プロフェッショナルSSL/TLS」と「RubyでつくるRuby」(参考：書籍『Ruby でつくる Ruby』が発売されます)が今朝発売開始されています。 「プロフェッショナルSSL/TLS」は、TLS(Transport Layer Security)の背景となる理論やプロトコルだけではなく、過去に発生したプロトコル上の脆弱性、運用上の脆弱性、実装上の脆弱性なども解説してあります。Webブラウザの問題も紹介されています。後半は、Apache、Tomcat、IIS、Nginx、などの設定方法の紹介です。 編集者であり技術者な鹿野さん 「プロフェッショナルSSL/TLS」を出版し
ざっくり詳解 - NAT64とDNS64:Geekなぺーじ
2016年6月から、iOSアプリの審査基準としてIPv4に依存するコードの禁止が追加され、IPv6対応がiOSアプリの義務なったことからも、IPv6に関する知識が必須となったエンジニアも多いのではないかと思います(Appleの発表)。 Appleのサイトでは、IPv4アドレス在庫枯渇の発生とともに、ユーザに対してIPv6のみによるインターネット接続性を提供するNAT64(「なっとろくよん」です。ろくじゅうよんではないです。)とDNS64という技術が、エンタープライズ網や携帯電話網で採用されることが増えているとあります。 Apple Developer: Supporting IPv6 DNS64/NAT64 Networks iOSアプリ開発者は、このNAT64とDNS64環境でもアプリが正しく動作することを求められています。 Appleのサイトでは、NAT64とDNS64はOS X 10
IPv4アドレスを含むIPv6アドレス表記:Geekなぺーじ
IPv6アドレスには、128ビットの中にIPv4アドレスを含むものがあります。 IPv4アドレスを含むIPv6アドレスを表記するとき、通常のIPv6アドレス表記だけではなく、最後の32ビット部分をドット「.」で区切ったIPv4アドレス表記で記載することもできます。 先ほど公開したNAT64+DNS64記事で紹介している「64:ff9b::192.0.2.33」というのも、IPv4アドレスを含むIPv6アドレスの表記方法です。 このようなIPv4アドレスを含むIPv6アドレスをテキストで表記する方法に関しては、RFC 5952(A Recommendation for IPv6 Address Text Representation)の5章でも解説されています。 IPv4射影アドレス(IPv4-Mapped IPv6 Address) IPv6アドレスの基本仕様(RFC 4291)には、IP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
