はじめに
セキュリティ・キャンプ 2024 ネクストに合格しました！
セキュキャンには応募課題晒しなる文化があると聞いたので、駄文ではありますが、今後応募する方々の参考になればと思い公開します。
※この応募課題にはかなり不正確な記述が含まれている可能性が大いにあります。中身云々ではなく、ネクストの課題ってこんな感じで書くんだなという見方をしていただけると助かります。
課題
www.ipa.go.jp
セキュリティ・キャンプ ネクストでは、広範囲な分野を深く理解し、新たな攻撃をいち早く見つけ、理解し、基盤から根本的な対策を講ずるために新たな価値を生み出していけるトップオブトップの人材、フルスタック・エンジニアと呼ばれる人材を発掘・育成することを目的とします。
またその修了後には、既存の受け皿に納まるのではなく、多くの人や技術を巻き込んで活躍することを期待しています。
このため自身の技術力だけでなく、新たな技術や未知の分野に抵抗感無く踏み出せるか、新たな発想や価値観を生み出せる素養があるか、といった点を評価します。 課題に対する回答の正否でなく、そうした点を見て総合的に判断します。
ぜひ、そのような視点で応募にのぞんでみてください。
（注意：過去のセキュリティ・キャンプ全国大会への参加の有無にかかわらず、応募が可能です。但し、セキュリティ・キャンプ全国大会との併願はできません。）
選考のポイント
基本として、加点法で判断します。
自身の技術力ややってきたこと、発信してきたこと、何ができるかといったことなど、アピールしたい点を存分に記述してください。
多く書くことにより、「文章が長過ぎる・まとまりが無い・重複している・冗長」などとして減点するようなことはありません。失敗した経験や落選の結果を書くことや、「文章が洗練されていない」「誤字脱字がある」などによる減点もありません(文章や作文のテストではありません。内容を見ます)。アピールをいっぱい書いて、得をすることはあっても、損をすることはありません。自身がアピールしたいことを思い付くままにいっぱい書いて、アピールしてください。
いかにやる気があるか、参加できたらいかに頑張ることができるか、ということを「示して」ください。「やる気があり、今までこうしたことをやってきています」「このようにいままでずっと手を動かしてきています」「こういったものを作ったことがあります」「今までこんな活動を継続してきています」ということを書くといいでしょう。それが、やる気を証明することになります。
課題については、課題が解決できたかどうかや正誤で判断するのではなく、いかに自身で疑問を持ち課題設定するか、その課題を解決しようとする過程や未知のことにどのように取り組むか、新たなことに挑戦しようとする姿勢を見ます。
このため課題は解決できなくても構いませんし、正答にたどりつけなくても構いません。課題に対する正答を求めているわけではありません。途中経過でも構いませんし、自分なりの考えでも構いませんので、いかに取り組んだか、難しい課題にこのように取り組んでこの辺りまではわかった、自分なりにこう考え、こういうことを調べた・試した、自分はこう考えこう思ったという、その過程を書いてください。自身のできる範囲で課題設定して回答するのでなく、ぜひ今まで知らなかったものに挑戦して、その挑戦の過程を書いてみてください。その結果正答でないとしても、それは挑戦しているためとして判断します。
手を動かしてみてください。ネット検索で調べたことを張り付けるだけではなく、本当にそうなのかという疑問を持ち、自分で手を動かして、見て、試し、調べ、確認し、本当にそうなのかと深堀りして考えてみてください。ネット検索で出てきたことは、はたして本当なのでしょうか︖深堀りして理解し納得できているでしょうか︖疑問点や矛盾は無いでしょうか(矛盾があるとしたら、その原因はどこでしょうか)︖自分の眼や手で確認したでしょうか︖他人に説明できるでしょうか︖そして、そうしたことを書いてください。課題解決に対する、そのような姿勢を見ます。
自分の提出したもの
※スライドは公開リンクに差し替えてあります
■ あなたに関する問い
あなたは今までどのようなことをやってきましたか．どのようなことができて，どのようなことが得意で，どのようなことに自信がありますか．
どのようなものを作りましたか．どのような情報を発信してきましたか．
どのようにしてそうしたことをやってきましたか．なぜ，そのようなことをやってきましたか．やってきてどう思いましたか．
参加できた場合，セキュリティ・キャンプ ネクストにどのようなことを期待し，どのようなことをやってみたいですか．
私は今まで、Web開発を中心にコンピュータへ触れてきました。インターンシップや業務委託などでフロントエンド/バックエンド/インフラそれぞれ一通り触っており、自分の得意分野といえばWeb開発だと思います。最近はシステムプログラミングにも手を出して、主にRustを中心に書いています。Rustを最初に書いて以来、その書きやすさに感動してずっとRustを書いています。特に感動したのがEnumとパターンマッチングで、Option型、Result型を最初に使った時は新鮮でとても驚きました。それまではNode.jsをメインで書いていたため、Option型でNull安全に書けるのはとても気持ち良いものでした。また、Result型とquestion mark operatorを使ったエラーハンドリングの綺麗さがとても好きです。Rustは得意と言えるレベルかはわかりませんが、大好きな言語です。
私が取り組んできたことはポートフォリオ（https://shinbunbun.info/ ）に記載していますが、その中から抜粋して（また、それに加えて）以下に私が今まで取り組んできたことを紹介します。
Rust製コンテナランタイム
github.com
【未公開スライドのため割愛】
コンテナの仕組みに興味があり、低レベルコンテナランタイムをRustで自作しました。Linuxのシステムコールまわりへの知識や、どのようにプロセスを分離しているかなどの理解が深まりました。
RustでMerkle-CRDTの実装
github.com
【未公開スライドのため割愛】
サイボウズ・ラボユースのシステムソフトウェア研究開発コースで、Merkle-CRDTというアルゴリズムを用いて分散KVSの実装に挑戦しました。いくつかの論文を参考に実装したため、そういった文献を読む力や、自分の知らないアルゴリズムを理解する力がつきました。結局KVSの実装までは至りませんでしたが、Merkle-CRDT上で動くG-Setの実装まではできました。
Hands-on LINE botの執筆
github.com
nextpublishing.jp
インプレス技術の泉シリーズからHands-on LINE botというLINEBotの入門書を出版しました。言語はNode.jsで書かれており、AWS LambdaへのデプロイやDynamoDBとの接続まで対応しています。この書籍を執筆するにあたっては、如何に初心者が自分の作りたいLINEBotを作れるようになるかという部分に焦点をおきました。リポジトリのコードは自分なりに改造がしやすいようになっており、このリポジトリをテンプレートにしてたいていのLINEBotを作れるように執筆しました。
Raftの実装
github.com
セキュリティ・キャンプ全国大会2023で分散合意アルゴリズムであるRaftをGoで実装しました。複数のレプリカがある分散システムにおいてどのように合意形成をとっていくかという部分の理解が深まりました。
Rust製LINEBotSDKの自作
github.com
RustでLINEBotを作る環境がなかったため、SDKから自作しました。自分が今まで触ったことのなかった型レベルビルダーパターンに挑戦し、開発しやすいSDKを作れました。
Rust製SNSアプリケーションの自作
github.com
株式会社ゆめみのインターンシップで、Rust製のSNSを実装しました。この時はRustに触るのが初めてだったため、Enumとパターンマッチングなど、関数型パラダイム特有の考え方をたくさん学習できました。また、actix-webなどを使ったRustでのWeb開発方法についても学習できました。
分散型台帳を使ったイベント参加者募集プラットフォーム
github.com
protopedia.net
IOTAという分散型台帳を使って、Decentralized Identifiers(DIDs)とVerifiable Credentials(VCs)を使ったイベント参加者募集プラットフォームを作りました。3人で制作し、自分はVCsの発行周りを担当しました。DIDsやVCs、IOTAの仕様書を読みながら実装したため、仕様書の読み方などを学習できました。
secp256k1をフルスクラッチ実装
github.com
ビットコインなどに使われているsecp256k1という楕円曲線暗号の署名アルゴリズムをRustを使ってフルスクラッチで実装しました。暗号は元から興味があり、高校生の頃から耐量子計算機暗号などについて学んでいたので、気付けば割と長い間触っている分野です。有限体の定義などから全て実装したため、署名アルゴリズムの理解につながりました。また、有限体、楕円曲線、それを用いた署名アルゴリズムをなるべく疎結合に実装し、再利用性を上げました。
自宅k8sサーバを立てる
NixOSが載っている自宅サーバでk8sを導入してmisskeyのサーバをたてました。クラウドでk8sを使ったことは何回かあったのですが、オンプレは初めてだったため、最初の構築の部分から学習できました。
ユーザースペースで事前に学習したニューラルネットワークの推論をeBPFプログラム（XDP）で実行し、カーネルレベルでIDSを実装する
【未公開スライドのため割愛】
NAISTの研究室インターンで、教授の研究に関する実験を行いました。eBPFも機械学習もあまり触ったことがなかったため、基本技術に関する勉強になりました。また、カーネルスペースで推論を動かすために量子化などの工夫を行う必要があるため、その点についてもとても勉強になりました。
WebAuthenticationの実装
ヤフー株式会社のインターンでGo言語を使ってWebAuthenticationのフルスクラッチ実装を行いました。こちらも仕様書をかなり読む必要があるタイプの開発でした。Go言語もWebAuthnも初めてだったため、その点でも勉強になりました。また、ペアを組んでのチーム開発だったため、どのようにコミュニケーションをとりながら開発を進めるかなども勉強になりました。
Agones上に作るQUICを使った音声通信機能に関する検証と開発
shinbunbun.hatenablog.jp
株式会社MIXIのインターンシップで、Agones上に作るQUICを使った音声通信機能に関する検証と開発を行いました。
このインターンではRustやGo、gRPC、Agonesなど様々な技術を学習できました。また、sendmsg, resvmsgなどのネットワーク系システムコールについて理解を深めることもできました。
自宅インフラ構築
上記のスライドにあるのは高校生の頃から学部1年までの記録です。PKIやL2VPNの構築など、私のネットワークに関する知識はここから得られた部分がかなり大きいです。現在は引っ越してNAT越えする必要がなくなったため、Rustビルド専用として買った12900kを積んだマシンを自宅においており、ポート解放&DDNSの設定をして外からSSHできるようにし、開発マシンにしています。
なぜ、そのようなことをやってきたかといえば、知的好奇心とコンピュータが好きな気持ちが大きかったと思います。基本的に技術は好奇心駆動で触ってきました。コンピュータは何を触っても楽しいし、面白そうなことが多すぎるので一生退屈しなさそうで嬉しいです。
ネクストキャンプに参加できた場合、私はシステムソフトウェア/低レイヤーに関してもっと知識をつけたいと考えています。今までWeb系を中心に触ってきたため、最近システムソフトウェアの領域に手を出しつつはありますが、まだそこまでしっかりさわれているわけではないのが現状です。そのため、そのあたりの知識や技能をつける一歩目にしたいです。ネクストの講義はFPGAやネットワーク周りなど、自分が興味があったり触っている分野ばかりなため、その辺りに関する知識/技能を身につけたいです。
■ 課題への姿勢に関する問い
自身で何らかの技術的な疑問を設定し，その疑問を解決しようと取り組み，その過程を示すことで，自身の技術力や課題に取り組むやりかたを説明してください．
(疑問の例：実行ファイルはどのような構造になっているのだろう？ pingコマンドを実行すると何が起きるんだろう？ オンラインゲームはどうやって通信対戦を実現しているのだろう？ といったようなことです)
設定する疑問は何でも構いませんし，解決しなくても構いません．
解決できたかどうかではなく，いかに課題に取り組むかという点を評価します．
課題: AWSのDynamoDBはどのような目的で作られてどのような仕組みになっているのか
私は触りたい技術があった場合、論文や仕様書(RFCなど)がある場合はそれを参照しにいくことが多いです。最初のとっかかりとしてQiitaなどのブログ記事を読むことは多々ありますが、色々開発をする中で一次情報をあたる重要性に気付き、しっかりと理解したい技術はできるだけ一次情報をあたるようにしています。査読論文や仕様書というものは色々な人のレビューが入った上で高い完成度の文書として公開されています。多少読むのが辛くても、最後はそこを参照するのが理解への近道だと思っています（とはいえ今回は時間の関係上、一部の技術に関しては一次情報をあたることができなかったことが悔やまれます）。
課題に関しては、論文[1]をベースに周辺知識を含めて調査しました。特に参照の記載がない場合は基本的に[1]を参照しています。
まずDynamoが開発された背景を整理します。
例えば、Amazonのショッピングカートサービスでは、ネットワークやサーバーの障害の中でも、顧客がショッピングカートにアイテムを追加したり削除したりできるようにする必要があります。しかし、従来のデータストアではこの要件を満たせていません。従来の多くのデータストアは、書き込み中に競合解決を実行し、読み取り処理が複雑にならないようにしています。しかし、そのようなシステムでは、データストアがある時点でレプリカのすべて(または大多数)に到達できない場合、書き込みを拒否することがあります。一方Dynamoは、書き込みが決して拒否されないようにするために「常に書き込み可能な」データストア(すなわち、書き込みに高い可用性を持つデータストア)として設計されています。
上記のようなユースケースに対応するためにDynamoは作られました。
また、Dynamoの設計において個人的に興味深かった点としてビザンチン耐性がないことがあげられます。
ビザンチン耐性のあるシステムとは、分散システムにおいてノードが悪意を持って偽の情報を伝達する・故障して誤った情報を伝達するなどの事象が起こった際に、全てのノードで合意を形成できることを指します。Dynamoは、そのようなデータの完全性やセキュリティの問題に焦点を当てずに、信頼できる環境を前提に設計されています。例えばブロックチェーンなどは悪意のある人間による市場に対する攻撃が行われる危険性があるためビザンチン耐性が必要ですが、Dynamoの場合はAWSというある程度信頼性の高い環境で動くことが想定されているため、あえて設計や運用が複雑になるビザンチン耐性の性質を持たせる必要がなかったのではと私は考えました。
次に、従来のreplicated relational databaseとの違いについて述べます。
従来のreplicated relational databaseはStrong Consistencyという一貫性に焦点を当てています。
Strong Consistencyとは、すべてのクライアントから見たすべての操作が何らかの順序で一貫しているというものです。[2]
私は、書き込みが行われた後に読み出しをした際、最新の更新が必ず反映されているものという解釈をしています。
このようなシステムはスケーラビリティと可用性に限界があり、例えばネットワークパーティションを処理することができないと[1]では述べられています。
ネットワークパーティションは、クラスターサーバー間の通信路に障害が発生し、クラスターサーバーがネットワーク的に分断されてしまう状態のことです。[3]
この場合、Strong Consistencyなシステムでは一貫性を保つために可用性を犠牲にする必要があると私は考えています。パーティションが解決されない状態でシステムがリクエストを受理すると、ノード間でのデータの整合性がとれなくなる可能性があるため、解決されるまでリクエストを受理することができず、可用性が低下します。
一方、DynamoはEventual Consistencyという一貫性を採用しています。
Eventual Consistencyは、あるデータ項目に新たな更新が行われなかった場合、最終的に（結果的に）その項目へのすべてのアクセスが最後に更新された値を返すことを非公式に保証するものです。[4]
書き込み（更新）は（1つ以上のノードが生きている場合）常に受理されるが、その後に読み出しをしてもその更新が反映されている保証はなく、しかし最終的には全てのノードの状態が収束して整合性が取れるようなものだと私は解釈しています。
このようなシステムでは、ノード間が同期される前に複数箇所で更新が起こった場合にコンフリクトが起こりうるため、収束させるためになんらかの競合解決メカニズムを実装する必要があります。DynamoではVector Clockという論理クロックの一種である手法が使われています。
このように、一般的にEventual Consistencyなシステムは一貫性を犠牲にする代わりに強い可用性を手に入れていると私は考えています。
ただし、Dynamoはquorum systemsを採用することで一貫性と可用性のバランスをとっています。
以下にquorum systemsに関する説明を記述します。以下は[1]に加えて[5]を参考に記述しています。
まず、R: 読み取り操作に参加しなければならない最小限のノード数、W: 書き込み操作に参加しなければならないノードの最小数、N: データが複製されるノードの総数とした時、R + W > Nの関係が成り立つようにRとWが設定されます。これにより読み取り操作と書き込み操作の間に少なくとも1つの共通ノードが存在することが保証されるため、最新のデータを読み込むことが可能になります。
RとWの値を調整することによって一貫性と可用性のバランスを調整することができます。例えばWを1に設定した場合、システム内に少なくとも1つのノードがあり、書き込み要求を正常に処理できる限り、システムは書き込み要求を拒否することはありません。これは可用性が高いと言えます。しかし、WとRの値が低いと、大多数のノードで処理されていない場合でも書き込み要求が成功とみなされ、不整合のリスクが高くなる（一貫性が損なわれる）と言えます。
Dynamoは上記のような形で、Eventual Consistencyを採用しつつ、一貫性が求められる場面ではそこを強化するといった調整ができるようになっています。
他にもDynamoに施されている工夫はたくさんありますが、私が興味を惹かれ、かつある程度理解できた範囲で上記にまとめました。一通り論文を読んでみた所感としては、そもそも作られた目的からしてかなり限られたユースケースで使われることを前提としているシステムだと感じました。一般的なアプリケーション開発では、Strong Consistencyが採用されているDBを使い、読み込み整合性が保証されている方が嬉しいのかなと思います。ただ、例にあげられていたショッピングカートのように、「常に書き込み可能」という制約がある状況においては、とても有益なシステムだと感じています。アプリケーション開発をする場面において、満たさなければいけない要件をきちんと考え、それに適したものを採用していく必要があるということに気付かされました。今まで分散システムの分野についてちょっとずつ勉強はしてきましたが、Dynamoについてちゃんと調査するのは初めてだったので、とても良い機会になりました。
参考文献
[1] DeCandia, G. et al. (2007) ‘Dynamo: Amazon’s Highly Available Key-value Store ’, Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles [Preprint]. doi:10.1145/1294261.1294281.
[2] Eventual consistencyまでの一貫性図解大全 (no date) Qiita. Available at: https://qiita.com/kumagi/items/3867862c6be65328f89c (Accessed: 20 May 2024).
[3] HAクラスター入門 ～用語解説3～ (no date) NEC. Available at: https://jpn.nec.com/clusterpro/blog/20171016.html (Accessed: 20 May 2024).
[4] 結果整合性 (no date) Wikipedia. Available at: https://ja.wikipedia.org/wiki/%E7%B5%90%E6%9E%9C%E6%95%B4%E5%90%88%E6%80%A7#cite_note-Vogels-1 (Accessed: 20 May 2024).
[5] 最近よく聞くQuorumは過半数(多数決)よりも一般的でパワフルな概念だった (no date) Qiita. Available at: https://qiita.com/everpeace/items/632831371da5ff215995 (Accessed: 20 May 2024).
■ 興味ある分野に関する問い
セキュリティ・キャンプ ネクストの講義の一覧を見て，その中から興味のある講義を選び，その講義で扱うテーマに対して自分が考えること，興味，疑問，課題，自分なりの考察などを説明してください．
その分野について知識があるかどうかではなく，いかに興味や疑問を持ち，課題を考え，自分なりに調べて考察するかといった点を評価します．
興味のある講義: Content Delivery Network を自作してみよう
CDNは普段Web開発をする時にたまに使っているので興味があります。以下に、CDNについて何も調べない状態で自分が考えていることを記述します。
自分が使ったことのあるCDNはCloudflareとAWSのCloudFrontです。例えばCloudFrontは高校生の時によく使っていたのですが、S3を使って静的ホスティングをした際に、S3を直接公開するよりもコストが安い、ACMで発行したサーバ証明書を無料でアタッチしてhttps対応ができるなどの理由だけで使っていました。私は、CDNの本来の利点はキャッシュができることとエッジ対応できることだと思っているので、あまり活かした使い方は出来ていないと感じています。この状態で自分が疑問に思っていることを以下に箇条書きします。
- どのようなアプリケーションであればCDNの利点をきちんと活用できるか
- DNSまわりがどのような仕組みになっているのか（例えばCDNを使わない場合はAレコードに自分のサーバのIPアドレスを記述しますが、CDNを使ってエッジする場合はアクセス元の地域によってアクセス先のIPアドレスが変わると思います。そのようなケースでどのようにDNSまわりが動いているのかが気になります。）
- 高速にレスポンスを返すためにどのような処理が内部的に行われているのか（サーバからそのまま返すよりもCDNから返した方が速いというイメージがあります。それが正しければ、どのような仕組みになっているのかが気になります。）
- DoS攻撃などに対する対策はどのように行われているのか（昨今だと機械学習を使って不審なパケットを分類する手法もあるため、CDNでそういったものが実装されているのか、他にもどのような手法で対策が行われているのかが気になります。）
以下は、上記の文章を書いた後に実際調べてみたことや考えたことをまとめています。
まず自分が感じた疑問点1つ目の「どのようなアプリケーションであればCDNの利点をきちんと活用できるか」についてです。
私が調べた中で一番メリットが大きいと感じたのは動画配信です。[6]によれば、動画ストリーミングにCDNを利用するメリットは、「視聴者との距離を最短にすることで、遅延を軽減」「オリジンサーバに負荷がかからない」「ストリーミングコンテンツがネットワークの帯域幅を超えない」などがあげられます。だいたい一般のコンテンツをCDNで配信する時のメリットと似通っていますが、動画というパケット量が多くなるコンテンツであるからこそCDNを使うメリットを引き出せるのではと感じました。
次に2つ目の「DNSまわりがどのような仕組みになっているのか」についてです。
[8]を読んだところ、エニーキャストという仕組みを使っていることがわかりました。[9]によれば、エニーキャストとは、着信リクエストをさまざまな場所（「ノード」）に転送できるネットワークアドレッシング／ルーティング方式のことです。要は1つのIPアドレスを複数のサーバに適用できる仕組みになります。Cloudflareがどのようにしてエニーキャストを実装しているかは[11]で紹介されていました。例えばCloudflareのDNSサービスのIPアドレスは173.245.58.205で、ホップが最も少ない経路で世界各国にあるCloudflareデータセンターのうちのどれかにパケットが送られます。例えば福島県会津若松市にいる自分がこのIPアドレスに対してtracerouteすると以下のような結果が返ってきます。
traceroute to 173.245.58.205 (173.245.58.205), 30 hops max, 46 byte packets
1 _gateway (192.168.1.1) 1.364 ms 1.034 ms 1.165 ms
2 fksnij41.asahi-net.or.jp (118.243.96.16) 3.987 ms 4.358 ms 3.805 ms
3 cs1bi2-v2228.asahi-net.or.jp (118.243.96.174) 8.570 ms 8.432 ms 8.538 ms
4 cs1cr4-v1151.asahi-net.or.jp (202.224.52.172) 14.744 ms 9.418 ms 24.212 ms
5 cs1ni3-v1173.asahi-net.or.jp (202.224.52.217) 9.330 ms 9.783 ms 9.648 ms
6 101.203.88.62 (101.203.88.62) 10.827 ms 25.958 ms *
7 103.22.201.38 (103.22.201.38) 11.398 ms 103.22.201.31 (103.22.201.31) 12.576 ms 103.22.201.38 (103.22.201.38) 11.068 ms
8 molly.ns.cloudflare.com (173.245.58.205) 12.830 ms 9.932 ms 9.858 ms
ipinfoで7番の103.22.201.38を検索すると、Cloudflare所有のIPアドレスで東京にあるデータセンターであることがわかります。
[9]の記事には、ロンドンやサンフランシスコから同じことをすると、それぞれの近くにあるデータセンターを通っていることが確認できると記述されています。
これらの技術を使うことで、ある1つのIPアドレスへのリクエストを地理的に近いデータセンターへルーティングできる（エッジ）ことがわかりました。
次に3つ目の「高速にレスポンスを返すためにどのような処理が内部的に行われているのか」です。
CDNでロード時間が短縮される仕組みは主に以下のものが挙げられます[11]
1. IXPにサーバを配置する[12]
IXPはISPやCDNなどが相互に接続しているポイントを指し、異なるネットワークのエッジと言えます。IXPにサーバを配置することにより、他のネットワーク間とのトランジットの経路を短縮でき、レイテンシー削減、RTTの改善などにつながります。
2. 距離の短縮
世界中にサーバがあるので（エッジ）、クライアントと要求されたデータの物理的な距離が短縮でき、結果RTTが短くなります
3. ハードウェア/ソフトウェアの最適化
SSDや効率的な負荷分散を用いてサーバ側のインフラストラクチャのパフォーマンスを高めることができます。
4. データ転送の削減
コードのミニファイやgzipなどでのファイル圧縮により、データ転送量の低減をしています。
最後に4つ目の「DoS攻撃などに対する対策はどのように行われているのか」についてです。
前述のエニーキャストがDDoS対策の1つとして挙げられます。[9]
エニーキャストはリクエストが複数のサーバに分散されるため、1つのサーバにトラフィックが集中することを防げます。
また、当初考えていた機械学習を使ったDDoS対策は、一般的にはCDNではなくWAFの責務であることがわかりました。
一通りCDNについて調べてみた所感としては、やはり静的なファイルを配信する際はCDNを使うことがとても有効であることがわかりました。ただし、動的なアプリケーションにCDNを挟んでしまうと、キャッシュされてはいけないものがキャッシュされてしまうため、使い所を慎重に選ばないと危ない面もあると感じました。そういった場面では自分が学んでいる分散システムが活きてくることもあるんだろうと考えています。
参考文献
[6] (No date a) 動画CDNとは？ | CDN動画ストリーミング | Cloudflare. Available at: https://www.cloudflare.com/ja-jp/learning/video/what-is-video-cdn/ (Accessed: 20 May 2024).
[7] (No date) CDNのメリット：CDNを使う理由は？. Available at: https://www.cloudflare.com/ja-jp/learning/cdn/cdn-benefits (Accessed: 20 May 2024).
[8] Cloud CDN の概要と仕組み | google cloud 公式ブログ (no date) Google. Available at: https://cloud.google.com/blog/ja/topics/developers-practitioners/what-cloud-cdn-and-how-does-it-work (Accessed: 20 May 2024).
[9] (No date a) How does anycast work? | cloudflare. Available at: https://www.cloudflare.com/ja-jp/learning/cdn/glossary/anycast-network (Accessed: 20 May 2024).
[10] Prince, M. et al. (2023a) Load balancing without load balancers, The Cloudflare Blog. Available at: https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/ (Accessed: 20 May 2024).
[11] (No date a) Cdn performance | cloudflare. Available at: https://www.cloudflare.com/ja-jp/learning/cdn/performance/ (Accessed: 20 May 2024).
[12] (No date a) インターネットエクスチェンジとは？ - Cloudflare. Available at: https://www.cloudflare.com/ja-jp/learning/cdn/glossary/internet-exchange-point-ixp (Accessed: 20 May 2024).
■ その他に関する問い
その他，アピールしたい点などあれば自由記述で回答してください．
私は自分が今まで触れたことのない技術に触るのが大好きです。自分の中に新しい知識が入ってくるとものすごくワクワクします。とにかく面白そうな技術だと思ったらなんでも飛びついてしまうタイプです。課題に取り組む過程でも色々調査しながら新しい知識が増えるのが楽しすぎて、本来掘るつもりではなかった部分まで掘り進めてしまいました。
今回のネクストキャンプも、私が深く触ったことのない技術が多く、講義一覧を見ているだけでワクワクが止まりません。今まで行ったインターンシップなども、全て自分が深く触ったことのない分野に挑戦できるものばかり参加してきました。今回もそのような挑戦をさせていただける場を提供いただけるのならとても嬉しいです。もし参加できることになった暁には、吸収できるものを貪欲に全て吸収し切って帰りたいと思っています。
