次世代のDNSサービスはコンテナ基盤へ！？ 内側から見たインターンシップの成果

こんにちは。BIGLOBE Style編集部の吉田です。

BIGLOBEでは、昨年に続き、今年も約2週間のエンジニアインターンシップを行いました！参加したのは、長崎県立大学3年生の齋藤脩愉さん。今回の記事では、インターンシップ成果発表会の様子をお届けします。

当初予定していた課題より、高度な取り組みにチャレンジすることになったという内容や、インターンシップを終えた感想など、どうぞご覧ください。

インターン生紹介

齋藤 脩愉（さいとう しゅうゆ）さん
長崎県立大学 情報セキュリティ学科 3年
研究：ネットワークの基盤分野に関する研究室
専門：ネットワーク、データベース

JANOGなどのネットワーク系コミュニティへ積極的に参加。今年7月に開催されたJANOG52では冒頭挨拶で会場の諸注意案内を担当した。また、若者のネットワークオペレーターズグループ「WAKAMONOG」再始動の仕掛け人でもある。その他、大学の授業アシスタント、サークルのインフラ運用担当を担っている。

インターンシップ期間

2023年9月4日〜9月15日 全10日間 （プロダクト技術本部 ネットワーク技術部 開発グループにて実施）

取り組んだ課題

キャッシュDNSのコンテナ化 〜DNSサーバーを現状の仮想基盤からコンテナ基盤へ移行する〜 今回のインターンシップ実働10日間で完了した一連のフロー 基盤となるコンテナイメージを生成し、意図した通りに動くか単体テストを実施 新旧バージョンのコンテナをDNSクエリの通信断なしで入れ替えられるように、スケールイン・スケールアウト機能を実装（以降、サービス断なしデプロイ、と呼びます） 　→ DNSはレスポンスが重要なため、AWSではなくBIGLOBEのデータセンターで運用 　→ Ansibleを活用してオンプレ環境のAmazon Elastic Container Service（ECS）Anywhere上にデプロイし、連動してロードバランサー（LB）を設定 入れ替え後、サービスの正常性を確認

課題の背景

現状、仮想サーバー基盤のマシンを使って、DNSのサービスを提供しているが、急にアクセスが増加した場合など、既存の基盤の制約で仮想マシンを迅速に増やすことができない。 そのため、DNSを軽量かつ柔軟なコンテナ上で動かすことで、SLA（Service Level Agreement）向上を目指す。 DNSのコンテナ化により、得られるメリット OS保守が不要 アクセス増加時のコンテナ自動追加（スケールイン）による性能向上 アクセス減少時のコンテナ自動削除（スケールアウト）によるコスト削減 各用途に向けたコンテナ構成を素早く構築可能

齋藤さん：今回のインターンシップでは、この計画の最初のステップとしてDNSをコンテナ基盤で動かすという評価を行いました。

DNSの基礎

みなさんが日常的に打ち込んでいるドメイン名ですが、実際はIPアドレスに変換して通信しなければなりません。そのドメイン名とIPアドレスを相互変換する仕組みをドメインネームシステム（DNS）と呼んでいます。

DNSには「権威DNS」と「キャッシュDNS」の2種類があります。

権威DNSは、ドメイン名とIPアドレスの紐づけ情報を持つデータベースのようなものです。基本的に利用者から直接アクセスされることはありません。

一方、キャッシュDNSは主に利用者からの問い合わせを受けて権威DNSに問い合わせます。その結果を一時的に保存（キャッシュ）して利用者に返す仕組みになっています。
利用者から同じドメイン名に対する問い合わせを受けると、権威DNSに問い合わせることなく、キャッシュしている情報を利用者に返します。

今回はこのキャッシュDNSに着目して取り組みました。
キャッシュDNSの構築に使用したのは、主にBINDやUnboundといったアプリケーションです。

取り組み内容

サービス断なしでキャッシュDNSを旧バージョンから新バージョンに入れ替えられるか、実験環境内で検証しました。その詳細をお話しします。

キャッシュDNSのコンテナ化（1日目、2日目）

キャッシュDNSのコンテナイメージを生成し、問題なく動作するかを検証環境にデプロイし、単体テストで確認します。正常動作の確認後、そのイメージをAWS上のコンテナレジストリにPushします。検証に使った環境は不要なので、消して元の状態に戻します。

これで基礎となるイメージは完成しました。次はそれを展開するための実装です。

サービス断なしデプロイ スケールアウト機能（３日目～５日目）

新しいイメージを使用するためのタスク定義を生成し、そのタスク定義、動かすコンテナ数（タスク数）を適用します。コンテナのデプロイ後、そのコンテナの構成情報を取得し、その情報を元にロードバランサー（LB）へ設定を投入。実際に通信が届くようにします。

サービス断なしデプロイ スケールイン機能（5日目、6日目）

スケールインの構成情報を先に取得し、サービス断なしが実現できるよう先にLBの設定を削除してコンテナに通信が届かないようにします。
この時点でコンテナを消しても問題ありませんので実際にスケールイン作業に入ります。これで一通り必要な機能は揃いました。

サービス断なしデプロイ（7日日～9日目）

流れは以下の通りです。

1. 新バージョンのデプロイ（スケールアウト）
2. 旧バージョンの削除　　（スケールイン）
3. サービス断なしデプロイ後の結合テスト

現状、利用者から受けた問い合わせをLBが各旧コンテナに負荷分散しています。
まず新バージョンのスケールアウト（増やす作業）です。新しいコンテナをデプロイして、LBに設定を投入します。これによって利用者からの通信が新バージョンのコンテナにも届くようになりました。
その後、旧バージョンのスケールイン（減らす作業）に入りますが、サービス断なしが目的ですので、まずはLBの設定を削除してコンテナに通信が届かないようにします。同様に、先ほどと同じ流れで新バージョンのコンテナデプロイ、LBの設定投入、旧バージョンの設定削除とコンテナのスケールインを行って、最終的に理想の状態にもっていきます。

今回このように複数の段階を踏んでいるのは、同時に稼働できるコンテナ数に制限があったため半数ずつスケールイン・スケールアウトを行う流れにしています。

一通りの機能は以上となります。

動作デモンストレーション

デモンストレーションの様子
一連動作デモンストレーションを行い、結合テストも問題なく完了

残課題とバグの発見

一見問題がないように見えていますが、今回時間が足りずにいくつか課題が残りました。

テスト結果が想定した通りのものであるかを自動的に判定する機構がない 　→人間が確認して判断する必要がある 作業の完了を固定秒で待機しているが、その時間内にデプロイが完了しない可能性がある 　→想定時間内にデプロイが完了しなかった場合、エラーが発生し後続の処理が行われなくなる 　→デプロイ途中の環境になってしまい、切り戻しが必要となる可能性がある 　→デプロイ状況をAnsibleを用いて監視し、状況の変化をトリガーにして次の作業項目（動作）に遷移すべき

今回のインターンシップでは概ね目標が達成できました。ただ、これらの課題は2週間という時間の制約上取り組むことができなかったので、もう1週間時間が欲しかったです。

一方、課題に取り組む中で、ツールのバグを発見することができました。それらの情報はグループメンバーを通じて、ベンダーへ情報提供できればと思います。

以上がインターンシップの成果です。

インターンシップを終えて

学んだこと エラーやトラブル発生時の原因切り分けのコツ Amazon ECSの操作や挙動 Ansibleの構文や挙動 目標達成までの流れ（入念な事前調査の重要性） 時間は有限であること（工夫や妥協）

インターンシップを通じて、コミュニケーションの重要性も学びました。些細なことでも質問することで作業の効率や品質の向上につながりますし、切り戻しを発生させないように認識を合わせることも大切です。相談しやすい環境であったことは大変ありがたかったです。

2週間という期間でしたが、高度な内容ながらも最終目標を達成できたことは、言葉では言い表せないくらいの達成感を得ることができました。また、これまで触れたことのないツールや技術要素を用いた業務は、常に新鮮で楽しかったです。

BIGLOBEは新しいことに挑戦したい人、自己研鑽したい人、自分が持つスキルを最大限に発揮したい人にとって、最適な企業であると強く実感しました。

インターンシップのコーチからひとこと

インターン生のコーチを務めた滝口敏行

滝口：この2週間本当にお疲れさまでした。学生レベルをはるかに超えたアウトプットをしていただきました。今回、次世代のDNSのコンテナ基盤を検証しようと計画しているところに、とても優秀なインターン生がいらっしゃると聞き、それならば検証をお任せしようかと無茶ぶりをさせていただきました（笑）。苦労しながらもここまで形にできたのは、齋藤さんのエンジニアとしての能力が確立されているからこそと思っています。私もエンジニアとして非常に刺激を受けましたし、齋藤さんのスキルセットの高さに非常に感服しました。今後社会人となられた暁には同じ界隈で一緒に仕事ができることを楽しみにしております。ぜひとも優秀なエンジニアとして活躍してください。

（左）代表取締役社長　山田　 （右）執行役員常務　高宮

最後に幹部からひとことずつ感想をいただきインターンシップ成果発表会は終了しました！

BIGLOBE Style編集部から齋藤さんへインタビュー

編集部：インターンシップお疲れさまでした！まず、BIGLOBEのインターンシップを選んだ理由を教えてください。

齋藤さん：もともとネットワークに興味があり、ISP（インターネットサービスプロバイダー）の運用や日常業務がどういうものなのか、大学のサークルや個人での運用とはどのような違いがあるのかを知りたくて参加しました。
会社で働く雰囲気を知って、将来の進路選択に活かしたいという目的もありました。

編集部：実際に参加してギャップに感じたことやBIGLOBEならではと感じたことはありましたか？

齋藤さん：大勢で取り組んでいると思っていましたが、少数精鋭で驚きました。また、耐障害性のため、構成の冗長化を徹底していることを聞き、品質の高さを実現する徹底ぶりはBIGLOBEならではだと実感しました。

編集部：今回のインターンシップで一番印象に残っていることは？

齋藤さん：初日ですね。当初はDNS移行のための評価のみと聞いていたので性能評価位かなと思っていたのですが、あそこまで大きな課題だったので愕然としました（笑）。

編集部：進めていく上で先輩社員や上司からはどのようなアドバイスがありましたか？

齋藤さん：たくさんアドバイスをいただきました。「こういう処理を考えている」と相談すると、最適な処理の仕方をアドバイスしてくれたり、今回初めて触ったツールについても「実はこういうことができるよ、こういう書き方ができるよ」と実務的なアドバイスをくれたりしました。助けがあったからこそ実現できました。

編集部：難しい課題でしたが、元々齋藤さんはどのようなスキルをお持ちなのでしょうか。

齋藤さん：小学4年生のころからコンピューターに興味を持って触れてきました。人間が命令すればなんでもできるので、魔法を見ているような気分でしたね。その頃から自分のやりたいことを実現するために独学に励んで、小学校高学年にはサーバーを借りていました。高校に入ってからは、理論を固めるためIPAの国家資格を継続的に取得しています。

根底にあるのは「コンピューターが好き」ということです。好きだとやりたいことがどんどん出てくるので、そのために勉強するという、僕にとっては遊びに近い感覚です。

今回インターンシップに参加して、AWSのスキルが得られたり、新しいツールに触れる機会に携われたりと、さらに自分のスキルを高めることができました。

編集部：齋藤さんの展望を教えてください。

齋藤さん：いずれはネットワーク業界をリードしていけるようなエキスパートになりたいです。

編集部：今後の成長と活躍を応援しています！ありがとうございました！

プロダクト技術本部 ネットワーク技術部 開発グループ

2025年卒向け新卒採用について

最後に、2025年卒向け新卒採用についてお知らせです。
現在、BIGLOBEのマイページではエンジニア職のエントリーシートを受付中♪
加えて、12月に開催するエンジニア職向けインターンシップの応募受付も開始しています！
少しでもBIGLOBEに興味をもっていただけた方は、新卒採用サイトにアクセス後、右上にあるメニューからマイページ登録をお願いいたします。

www.biglobe.co.jp

▼マイページ登録へ直接アクセスしたい場合はこちらからお願いいたします。

https://mypage.3050.i-webs.jp/biglobe2025/applicant/login/baitai-entry/entrycd/Style
※アクセス後、右下にございます「初めての方はこちら」より、新規登録をしてください。

※Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。
※ 記載している団体、製品名、サービス名称は各社またはその関連会社の商標または登録商標です。