名古屋支社所属。新しい技術・怪しいデバイス・GISが好き。名古屋から影響力のある開発チームを作って発信していくのを目標としている どうも名古屋支社の北河です。 普段はアジャイルな日々で情報発信をしていますが、今回はいつもと趣向を変えて位置情報に関係する話をしたいと思います。 位置情報は私が所属している名古屋技術4課が得意とする「みまもりサービス」で必須な技術要素です。そんな位置情報を扱ううえで知らないと背筋がゾッとする怖い話をしたいと思います。 位置情報でハマる測地系問題 位置情報を使ったみまもりを実現する場合、大抵は地図にプロットしますよね？ そんな地図にプロットする時に意識しないといけないのが測地系です。 測地系って聞いて何を思い浮かべますか？おそらく大半の方が “何それ？” ってなると思います。 でも、位置情報を扱う時はちゃんと意識しないと下図のようなパチンコガンダム駅が生まれちゃう

◆仕事：基盤エンジニアリング本部基盤技術部所属。2001年IIJ入社以来、お客様に提供するサービスを裏側から支える部署でサーバインフラの業務に従事。サービス向けのプライベートクラウドを作る業務から、サーバに詳しくなり、ストレージ・ネットワーク・配線工事・電気・データセンターにも興味を持つ日々。白井DCCのサーバールーム内のフロア設計するにあたりデータセンターチームと共同で仕様を検討。　◆資格：第二種電気工事士/工事担任者(総合通信)　◆趣味：安い航空券を見つけて旅に出かけること 【IIJ 2022 TECHアドベントカレンダー 12/16（金）の記事です】 はじめに 私の家族構成は妻と子供二人です。これまで住んでた家が手狭になり、上の子が小学生になるタイミングでちょうどよい物件を見つけ、引っ越しました。 その物件には、共用設備としてマンションインターネットが敷設されていて、共用部から専有部

結構長くゲーム業界に出向していましたが、2022年秋に戻ってきました。ゲーム業界での経験も生かしながらIIJのエンジニアとしてちょっと面白いことを提供できていければいいなぁと思っています。格闘ゲームの世界チャンピオン(Evo2017)になった従兄弟がいますが彼にゲームを教えたのは僕ではありません。マスターリーグ大変そう、あと取締役就任おめでとう！ 【IIJ 2022 TECHアドベントカレンダー 12/11（日）の記事です】 皆さんはStarlink(スターリンク)をご存知でしょうか？通信衛星経由でインターネットに繋ぐ事ができるサービスです。今年の1月におきたトンガの火山噴火では同国のインターネット復旧に使われたり、ロシアによるウクライナ侵攻では、ウクライナ支援で活躍したりで色々な意味で世界中から注目されています。事業主はあのイーロン・マスク氏です。そのサービスが10月から日本でも利用でき

セキュリティ本部セキュリティビジネス推進部セキュリティオペレーションセンターに所属。2019年新卒入社。大学生時代より情報セキュリティにまつわる研究・開発をしている。インターネットが好き。 【IIJ 2021 TECHアドベントカレンダー 12/20（月）の記事です】 こんにちは。naotです。 普段はIIJのセキュリティオペレーションセンター（SOC）で、ログ分析ルールの管理やスレットハンティングのお仕事をしています。 1年目から小ネタでエンジニアブログのアドベントカレンダーを書かせていただいていて、もう3年目です。 私の一番長く続いている趣味は迷惑メール観賞です。 だいたい小学生時代から受け取りたいメールとそうでないメールの分類や、怪しいメールの観賞をしていました。 怪しいメールは集めるとその中に関連性やストーリーを見いだせることがあり、鑑賞だけでなく収集にも興味を持つようになった結果

【IIJ 2021 TECHアドベントカレンダー 12/1（水）の記事です】 今年で5回目を迎えるIIJのTECHアドベントカレンダー。 昨年までのものは以下にまとめていますので、見逃している方はぜひご覧ください！ IIJ 2020 TECHアドベントカレンダー開催！ IIJ 2019 TECHアドベントカレンダー 開催！ IIJ 2018TECHアドベントカレンダーはじめます IIJ 2017TECHアドベントカレンダー開始します 2021年のラインアップ 今年も様々なネタを予定しています。 ネットワークやセキュリティ、IoTのほか、IIJの社内研修「IIJ Bootcamp」、業務プロセスの自動化を図る「Power Automate」、コンテナ化したアプリケーションのオーケストレーションシステム「Kubernetes」、今話題の「メタバース」、ひょっとしたらみなさんもお使いのキーボード

【IIJ 2021 TECHアドベントカレンダー 12/16（木）の記事です】 IIJ Raptorサービス部のエンジニア、RyuSAです。普段はアプリケーションの実装やアーキテクチャ、最近はKubernetesを使った業務を担当しています。 私事ですが、先日IIJの制度として発表された「セレクトジョブ」に参加し、SRE推進部という部署に兼務するようになりました！>  IIJ、社員の自律的なキャリア形成を支援する公募型兼務制度「セレクトジョブ」を開始 | IIJについて | IIJ さて本題に入りますが……自分は今年の春に「おうちKubernetes」を植え、自宅で育ててきました。 > おうちKubernetesを構築した話 – メモ – RyuSA (hatenablog.com) 残念ながら自分の家庭はサーバラックがあるような、俗に言う「逸般の誤家庭」ではないためできることはかなり限ら

Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 「フロー制御」の回で説明したように、輻輳制御とは途中のネットワークが溢れないようにするための仕組みです。QUICは、正確なRTT計測や、前回説明した簡潔なロス検知の機能を提供しています。このため輻輳制御としては、パケット欠落や遅延といったシグナルを使うアルゴリズムが利用可能です。RFC9002では、デフォルトの輻輳制御アルゴリズムとしてNewRenoを採用しています。 1990年に現れたRenoは、1995年に出されたアイディアに基づいて改良されNewRenoとなりました。2008年に提案されたCUBICや、2016年に現れたBBRに比べると、NewRenoは古い輻輳制御アルゴリズムです。QUICのデフォルトの輻輳制御に古いNewRe

Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 前回の説明では、「Initial パケット」や「Version Negotiation パケット」といった用語を未定義で使いました。今回は、こういった「パケット」や「フレーム」が、どのような構造を持っているかについて説明します。 古典的なパケット IP、UDP、およびTCPでデータをやり取りする基本単位は、すべて「ヘッダ＋ペイロード」という構造を持っています。このヘッダ＋ペイロードという単位は、それぞれ以下のように呼ぶのが慣習です。 IP – パケット UDP – データグラム TCP – セグメント すべてパケットと呼んでも間違いではありません。UDPの場合、IPペイロードが「UDPデータグラム(UDPヘッダ＋UDPペイロード)」に

IIJ Raptorサービス部のエンジニア、RyuSAです。普段はアプリケーションの実装やアーキテクチャ、最近はKubernetesを使った業務を担当しています。 唐突ですが、こんなものが作りたいな〜と思いたちました。 複数のRaspberry Piを物理的に分散して配置、それぞれのPi上でWi-Fi APを起動し同一のSSIDとパスワードを設定……とすれば、クライアント側でローミングして途切れにくいWi-Fi環境を簡単にセットアップできそうだなと🤔 というのも、個人的な話で恐縮ですが今自分の住んでいる部屋がざっくりこのような形をしております。 ブロードバンドルータと寝室の間にリビングとキッチン、そして壁が挟まっています。このせいでか寝室にWi-Fiの電波が少し届きにくいのが現状です。 もちろん新しい”つよつよ”なWi-Fiルータを購入して敷設すれば良いだけの問題なのですが、わたくしこれ

Kubernetesの主要なリソースの一つにServiceリソースがあります。ServiceリソースとはKubernetes上のPodへクラスタの外からアクセスするために使うもの、という理解をしている人が多いかもしれません。確かにそのような役割を担っているのですが、実際にはクラスタ内部に閉じた通信にも利用されていますし、実はもっといろいろな機能を持っています。 端的に説明すれば、Serviceとは「ロードバランサとDNSサーバを設定するためのリソース」です。意外に聞こえますか？ もし意外に思えたなら、ぜひこのまま読み進めてみてください。 インターナルなロードバランサを制御する Kubernetesにはクラスタ内部に閉じた通信を制御するロードバランサが内蔵されています。Kubernetesを利用するということは、ほぼ例外なくこのロードバランサを利用しているのですが、あまり意識せずに利用されて

ネットワーク技術部の竹﨑です。IIJには2020年度に新卒で入社し、IIJバックボーンの運用に携わる部署で働いております。過去にはこのような記事を投稿しております。 今回は私が電電・インフラ設備オタクになったきっかけの一冊をご紹介いたします。 はじめに 電話はなぜつながるのか そもそも書籍のタイトルである「電話はなぜつながるのか」と考えたことがある方は非常に少ないと思います。電話は水道電気ガスや“インターネット”と同じインフラであり、蛇口を捻れば出てくる水やケーブルを挿せばつながるインターネット( 最近ではケーブルをつなぐことは少ないかもしれませんね:) )のように受話器を上げて特定の番号へダイヤルすれば当たり前のようにつながるものとなっています。インフラ全般に言えることですが、当たり前に使えるということは驚くべきことです。しかし、あまり意識されることはありません。そのような当たり前だけど

社会人生活の半分をフリーランス、半分をIIJで過ごすエンジニア。元々はアプリケーション屋だったはずが、クラウドと出会ったばかりに半身をインフラ屋に売り渡す羽目に。現在はコンテナ技術に傾倒中だが語りだすと長いので割愛。タグをつけるならコンテナ、クラウド、ロードバイク、うどん。 筆者がIIJでパブリッククラウドビジネスを率いていた2010〜2015年頃、今後のITインフラはしばらくIaaSを中心に回っていくのだと考えていたものですが、Docker, Kubernetesという爆弾が投下されました。10年、20年は続くと思われたIaaSの時代がまさか早々に色あせて見えるとは。相変わらずIT業界にも思いもよらないことが突然起こるものです。これだからIT業界はおもしろい。 本連載は、現在IIJでSREを率いている筆者がどのようにしてSREチームを立ち上げ、Kubernetes沼へ飛び込み、悪戦苦闘し

2019年新卒入社。基盤エンジニアリング本部兼クラウド本部所属のKubernetes大好きエンジニア。自宅ラックマウントサーバ勢。休日はコスプレしたり、バイクに乗ったり、絵を描いたり、サーバメンテしたり、激渋旅館を巡ったりしてます。 こんにちは、IIJの韮塚(にらづか)です。 私は名古屋支社の技術部に所属しており、普段はインフラ中心のSI業務と開発向け社内ツールの管理業務をしています。 みなさん、Kubernetesは触っていますか？ いま世の中ではKubernetesが急速に普及しつつあります。 大手クラウドベンダーは独自にカスタマイズしたKubernetesをサービスとして提供しており、多くのWebサービスがその基盤を利用して稼働しています。 中にはYahoo!やサイボウズのように、自社内で独自にカスタマイズしたKubernetesを持っており、その上で自社サービス提供するような会社も

IIJ ネットワーク本部アプリケーションサービス部・(兼)社長室所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。 ここ最近、複数のお客様から「先月、迷惑メールが増えたんですが、なぜですか?」、という問い合わせをよく受けます。 結論を先に書くと、私はスパマーではないので、迷惑メールが増えた理由は分からないのですが、確かに IIJ で管理している計測システム宛の流量が、ここ最近激増しています。 今回は、ここ数か月の間に観測している、迷惑メール・ウイルスの総量とトレンドを報告いたします。 迷惑メールが最大 80倍に激増 次のグラフは、計測システム環境で受信した、日ごとの迷惑メールの総数

一言紹介 「Webエンジニア、プログラマーの必読書、これを読んだ前と後では世界の見え方が違ってくる良書、脆弱なコードを例示し、初心者にもわかりやすくその問題点を解説しており、だれが読んでもためになることは保証できる。」(システムクラウド本部 クラウドサービス2部 運用技術課) リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

はじめまして。k-nagaseと申します。 IIJオブジェクトストレージサービスの開発運用に携わっているエンジニアです。 今回は新人エンジニアにオススメする技術書の紹介ということで、「テスト駆動開発」を取り上げます。 ソフトウェア開発に携わり始めた方にぜひ読んで欲しい本です。 テスト駆動開発について 本書はテスト駆動開発を考案した張本人であるケント・ベックさんが、テスト駆動開発について書いた唯一の本です。また、翻訳は日本におけるテスト駆動開発の第一人者である和田卓人さんが手掛けています。 内容としてはそのままズバリで、ソフトウェア開発手法の1つであるテスト駆動開発について書かれています。 テスト駆動開発は「動作するきれいなコード」を追い求めるためのソリューションの1つです。 今までの基本であった「要件定義→設計→実装→テスト」というよく知られている開発プロセスとは異なったもので、最初は私も

IIJ ネットワーク本部アプリケーションサービス部所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。 IIJ 古賀です。普段は、IIJ セキュア MX という迷惑メールフィルタサービスの運用業務に従事し、お客様を守るために、毎日世界の悪と戦っています。 今週は「新人エンジニアにオススメする技術書」というテーマでお送りします。 早速なのですが、この「UNIXという考え方」は、厳密には技術書ではないかもしれません。なぜなら、この本は UNIX という OS が(または Linux に代表される “UNIX-like” な OS が)、どのような人々の思想のもとに設計され、進化しているか

はじめに 先日、「IIJ DNSプラットフォームサービス」という新たな権威DNSサービスをリリースしました。プレスリリースはこちら。 そしたら、どーまえさんから「新サービスでやってるスゴいことについて記事書いてよ、それも主なものだけかいつまんで紹介するんじゃなくて細かいところまで全部！」とリクエストされました。「え、まじで全部書くんすか？！むっちゃ多いっすよ──。」 IIJのDNSサービスはかなり頑張ってるつもりですが、うちだけじゃなく、同業他社さんや、あるいは自前でDNSサーバを構築運用している企業さんにも頑張ってもらいたいんですよね。営業の立場からすると「ぜんぶIIJに任せてくれや」となるんでしょうけれど、売り文句にマルチプロバイダとあるように、IIJ単独じゃなくて複数のDNS事業者で同じゾーンを持つことで耐障害性を高めよう、ということも今回のサービスのポイントなのです。 IIJのサー