Hybrid Cloud 上の Kubernetes 検証
この記事は，2022年3月1日から4月8日までの期間で参加した MIXI のインターン（Dive into MIXI GROUP 2021-2022 冬季）で行った内容をまとめたものです．
背景
Kubernetes のマネージドサービスである GKE(Google Kubernetes Engine) を利用するために必要な料金のうち，主要なものは以下の3つです．
このうちネットワークの料金については，データ転送量に比例して金額が上がっていきます． したがって，データ転送量が大きいサービスを GKE 上で動かす際には，ネットワークの料金が非常に高くなってしまいます．
リアルタイムでキャッシュが難しく，かつトラフィック容量が大きい WebRTC などのサービスを対象としてオンプレミスに逃すために，オンプレミス上で Kubernetes を構築することが求められていました．
CNI
CNI(Container Network Interface) プラグインとしては，cybozu-go/coil を採用しました．以下の2点が主な理由です．
- BGP スピーカが組み込まれていない
- 軽量で導入が容易
BGP スピーカが組み込まれていない CNI プラグインを採用したのは，MIXI が所有しているオンプレミス上の各サーバでは BGP スピーカが自動で立ち上がるように設定されていて，BGP スピーカがすでに組み込まれている Calico などを使用することが困難であったためです．
全体設計
全体設計は以下の図のとおりです．
LB や DNS を用意する手間を省くために，Control Plane Node は GCP 上で動かすように設計しています． また，オンプレミスのリソースが足りなくなった際に容易にスケールができるようにするために，Worker Node はオンプレミス上だけではなく GCP 上でも動かすように設計しています．
オンプレミス上の各サーバでは前述した BGP スピーカが立ち上がっており，BGP を用いて経路交換を行っています． それに加えて，オンプレミス上の Gateway と GCP 上の Cloud Router 間で BGP を用いて経路交換することにより，各サーバに割り当てられた pod-cidr の情報を交換しています．
ネットワーク要件
Kubernetes に求められる要件の1つとして，「クラスタ内の全ての Pod はクラスタ内の他の Pod と NAT なしで通信できなければならない」というものがあります． つまり，各 Pod に割り当てられた Internal IP を用いて通信できなければなりません．
今回の設計の場合，考えられる通信経路は以下の4つです．
それぞれについてどのようにパケットが送られるかを確認していきます．
考えやすいように，以下の図のように Internal IP, pod-cidr が割り当てられているとします．
オンプレミス→オンプレミス
Pod1(10.240.1.1) から Pod2(10.240.2.1) へパケットを送る場合を考えます．
- Pod1 は，Pod1 内の routing table を参照して，Node1 上にパケットを送ります
- Node1 は，Node1 内の routing table を参照して，オンプレミス上の Gateway にパケットを送ります
- オンプレミス上の Gateway は，Gateway の routing table を参照して，Node2 にパケットを送ります
- Node2 は，Node2 内の routing table を参照して，Pod2 にパケットを送ります
このように，各 Pod に割り当てられた Internal IP を用いて通信することができます．
ここで重要なことは，
- オンプレミス上の各サーバが行う BGP によって， オンプレミス上にある Node に割り当てられた pod-cidr とその Node の Internal IP の情報を Gateway が持っている
ということです．
GCP→オンプレミス
次に，Pod3(10.240.3.1) から Pod1(10.240.1.1) へパケットを送る場合を考えます．
- Pod3 は，Pod3 内の routing table を参照して，Node3 上にパケットを送ります
- Node3 は，Node3 内の routing table を参照して，VPC 内の Gateway にパケットを送ります
- VPC 内のGateway は， VPC 内の routing table(Routes) を参照して，オンプレミス上の Gateway に VPN を用いてパケットを送ります
- オンプレミス上の Gateway は，Gateway の routing table を参照して，Node1 にパケットを送ります
- Node1 は，Node1 内の routing table を参照して，Pod1 にパケットを送ります
このように，各 Pod に割り当てられた Internal IP を用いて通信することができます．
ここで重要なことは，
- Cloud Router を用いた BGP によって，オンプレミス上にある Node に割り当てられた pod-cidr とオンプレミス上にある Gateway の Internal IP の情報を Routes が持っている
- オンプレミス上の各サーバが行う BGP によって， オンプレミス上にある Node に割り当てられた pod-cidr とその Node の Internal IP の情報を Gateway が持っている
ということです．
オンプレミス→GCP
次に，Pod1(10.240.1.1) から Pod3(10.240.3.1) へパケットを送る場合を考えます．
- Pod1 は，Pod1 内の routing table を参照して，Node1 上にパケットを送ります
- Node1 は，Node1 内の routing table を参照して，オンプレミス上の Gateway にパケットを送ります
- オンプレミス上の Gateway は，Gateway の routing table を参照して，GCP 上の Cloud VPN に VPN を用いてパケットを送ります
- Cloud VPN は，VPC 内の routing table(Routes) を参照しますが，10.240.3.1 がどの Node にあるかが分からないため，パケットは Node3 に送られません
このように，各 Pod に割り当てられた Internal IP を用いて通信することができません．
ここで重要なことは，
- VPC 内で，どの pod-cidr がどの Node に割り当てられているかという情報が広告されていないため，適切な Node にパケットを送ることができない
ということです．
GCP→GCP
最後に，Pod3(10.240.3.1) から Pod4(10.240.4.1) へパケットを送る場合を考えます．
- Pod3 は，Pod3 内の routing table を参照して，Node3 上にパケットを送ります
- Node3 は，Node3 内の routing table を参照して，VPC 内の Gateway にパケットを送ります
- VPC 内のGateway は， VPC 内の routing table(Routes) を参照しますが，10.240.4.1 がどの Node にあるかが分からないため，パケットは Node4 に送られません
このように，各 Pod に割り当てられた Internal IP を用いて通信することができません．
ここで重要なことは「オンプレミス→GCP」の場合と同様に，
- VPC 内で，どの pod-cidr がどの Node に割り当てられているかという情報が広告されていないため，適切な Node にパケットを送ることができない
ということです．
Routes
以上のように，クラスタ内の全ての Pod がクラスタ内の他の Pod と NAT なしで通信できるようにするためには，どの pod-cidr がどの Node に割り当てられているかという情報を Routes が所持している必要があります．
Routes は，GCP のコンソール上や gcloud コマンドを用いて操作することができますが，手動で行おうとすると面倒であるだけではなく，ミスが発生しやすいです．
そこで，cybozu-go/coil が管理する pod-cidr の情報を監視して，Routes を管理するようなカスタムコントローラを作成することにしました．
カスタムコントローラ
カスタムコントローラの設計は以下の図のとおりです．
ここで，図に登場するカスタムリソースは以下のとおりです．
- AddressBlock
- cybozu-go/coil が管理するカスタムリソース
- Node に割り当てた pod-cidr の情報など
- Route
- 今回新しく定義したカスタムリソース
- Routes に作成する routing 情報など
実装したカスタムコントローラは route-controller と groute-controller の2つで，それらは route-controller-manager によって管理されているという構成になっています．
route-controller は cybozu-go/coil が管理する AddressBlock リソースを監視して，Route リソースを管理します．このコントローラは Route リソースを管理するだけで，Routes に対しては何も操作を行いません．
groute-controller は route-controller が管理する Route リソースを監視して，Routes を管理します．
リソースの削除
AddressBlock リソースが削除された場合，それに紐づく Route リソースや Routes は削除されるべきです．
今回の設計では，route-controller は AddressBlock リソースを監視しているため，AddressBlock リソースの削除を検知することができ，それに応じて Route リソースを削除することができます． また，groute-controller は Route リソースを監視しているため，Route リソースの削除を検知することができ，それに応じて Routes を削除することもできます．
しかし，削除のイベントが何らかの理由で取りこぼされてしまうと，削除されるべきものが削除されないまま残ってしまうといった問題があります．
そこで今回は，owner reference を用いて Route リソースの親リソースに AddressBlock を指定し，finalizer の機能を用いて Routes が削除されるまで Route リソースが削除されないように制御することで解決しました．
host network
groute-controller は Routes の作成・削除を行うために，Google Compute Engine API を叩く必要があります．
しかし，groute-controller が Routes の作成を行うときには，GCP 上の Pod への経路がまだ確立しておらず，API を叩くことができないといった問題があります
そこで今回は，groute-controller が host network 上で動くように設定することで解決しました．
reference
- https://cloud.google.com/kubernetes-engine/pricing
- https://cloud.google.com/vpc/docs/routes
- https://github.com/cybozu-go/coil
- https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/
- https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/
- https://zoetrope.github.io/kubebuilder-training/
delyのインターンでクラシルを開発した話
2021年7月26日〜2021年8月13日で，dely 株式会社が企画する就業型サマーインターンシップに参加していました．
今回はこのインターンの振り返りをしていこうと思います．
dely株式会社とは
dely 株式会社とは，レシピ動画サービスである「クラシル」 や女性向けメディアサービスである「TRILL」 を開発している会社です．
その中でもクラシルは，アプリダウンロード数3,000万を突破している国内 No.1 規模のレシピ動画サービスです．
今回のサマーインターンでは，このクラシルの開発に携わりました！
選考の流れ
- 暗号課題
- エンジニア面接
- ケース面接
といった流れでした．
暗号課題は，特に難しいものではなかったのですが面白かったです．適当に応募する人数を減らすような意図があったと思います．
また，エンジニアのインターンシップの選考に，ケース面接があるのはかなり珍しいと思いますが，「dely ではカルチャーを大事にしていて，技術力はもちろんだが，"なぜやるのか" などを共感した上でできる人が良い」という意図があるらしいです．
やったこと
使用技術
以下のような技術を使用しました．
- Ruby on Rails
- RDS
- DynamoDB
タスク
以下のようなタスクを行なっていました．
- クラシルの新サービスの機能開発1
- 仕様書設計
- API ドキュメント作成
- 実装
- デプロイ
- クラシルの新サービスの機能開発2
- 仕様書設計(WIP)
- 不足していたテストコードの追加
新サービスの内容は公式に発表されてからのお楽しみですが，ただ実装を行うだけでなく，仕様書設計から担当させてもらいました．
仕様書には，「その機能が必要になった経緯」や「どのような流れで処理を行うか」，「その流れに決めた理由」などを記載し，機能開発に携わっている人以外と同じ認識を共有できるように努力しました．
「その機能が必要になった経緯」をはっきりさせることで，実は必要ではない機能開発を未然に防ぐことができたり，同じ目的を達成するためのより良い方法がないかを模索できたりします．
さらに，同じ認識を共有することにより，レビューがしやすくなったり，今後の開発に役立つといったメリットもあると思います．
また，新サービスの機能開発1については，サマーインターン中に本番環境にまでデプロイすることができ，とても良い経験ができたと思います．
学んだこと
このインターンに参加するまで触ったことがない言語だったので勉強になりました．
開発速度を重視するサービスにおいて Ruby on Rails が優れていると感じた反面，保守性などについては考えなければならないことがあると感じました．
Ruby on Rails を書いていて詰まったりした部分などはここにまとめてあるので，よければ参考にしてください．
- DynamoDB
これも Ruby on Rails と同様に，インターンに参加するまで触ったことのないインフラだったので勉強になりました．
DynamoDB がどのような特徴を持ったもので，どのようなユースケースでよく用いられるものなのか，どのようなことが実現可能かなどを学びました．
自分用にある程度まとめてあるので，どこかで技術記事としてまとめたいと思っています．
- dely
急成長しているミドルベンチャーである dely のカルチャーや働き方，今後の展望などを学びました．
メガベンチャーに比べると人数が少ないということを生かし，意思決定などが迅速に行われていると感じました．
また，意思決定に関しても，定性的に評価するのではなく，しっかりと仮説を立てた後，データを用いて定量的に評価していると感じました．
感想
3週間という長くはない期間でしたが，学ぶことが多いインターンでした．
特に，CTO や VPoP，PdM の方などと話す機会を設けていただけたのが個人的にとても良かったです！
また，1週間だけ出社したのですが，オフィスが開放的で，すぐ近くに CEO や CTO の方などがいるという空間が刺激的でした！
3週間ありがとうございました！！！
AbemaTVのBackend Teamでインターンした話
2021年5月11日〜2021年5月31日で，CyberAgent が企画する就業型インターンシップ CA Tech Job に参加していました．
私は，AbemaTV の PBU開発局 / Backend Team に配属され，開発を行っていました．
今回はこのインターンの振り返りをしていこうと思います．
選考の流れ
私の場合，募集要項の選考フローとは少し順序が違い，
- ES
- 人事面接
- エンジニア面接
といった流れでした．
人事面接後に受け入れ候補の事業が「ABEMA」であることが伝えられ，エンジニア面接では「ABEMA」のエンジニアの方に面接していただきました．
人事面接・エンジニア面接ともに，受け答えがしやすい雰囲気を作ってくれているように感じました．
配属先について
株式会社 AbemaTV とは，「ABEMA」というサービスを持つ会社です．
「ABEMA」は、2016年4月に本開局した、テレビ＆ビデオエンターテインメントとして展開する動画配信事業。国内唯一の緊急・速報をはじめとした 24 時間編成のニュース専門チャンネルや、オリジナルのドラマや恋愛リアリティーショー、アニメ、スポーツなど、多彩な番組をお楽しみいただけます。
PBU とは，Premium Business Unit の略で，主に認証周りや課金回りを担当している開発局のことです．
私は，その PBU 開発局 の Backend Team に配属されました．
やったこと
主に認証改善系のタスクを行なっていました．
使用技術
インターンの中では，以下のような技術を使用しました．
- Go 言語
- gRPC
- gRPC gateway
- Spanner
タスク
認証改善周りの以下のようなタスクを行なっていました．
-
管理者側 API の実装
-
HTTP middleware の実装
特定の API レスポンスをキャッシュするために．Cache-Control ヘッダーを適切に設定するような middleware を実装しました．
- native 用 Content-type の対応
application/protobuf でやりとりできるように，gRPC gateway に Marshaller を追加しました．
- proto ファイルへのレスポンスの追加
定義されていなかった異常系のレスポンスを追加しました．
- エラー伝播周りの実装
レポジトリ内で定義されている private error を適切な gRPC status codes に変換するような interceptor を実装しました．
- コード生成系のコンテナ化
各開発者の clang-format や protoc のバージョンの違いにより，生成するコードに diff が発生してしまっていたため，コード生成系のためのコンテナを作成し，コンテナ内でコード生成を行うようにしました．
学んだこと
技術面
技術面ではかなり多くのことを学んだので，いくつかピックアップします．
- 認証周りの知識
認証の流れや，セキュアにするためにはどのような処理が必要なのか，実際に Go 言語を用いてどのように書くのかなどを学びました．
認証周りはなかなか触れることのできないセンシティブな部分だと思うので，とても良い経験になりました．
- 保守性や可読性を高めるための知識や方法
functional option pattern や，DI パターンなどを学びました．
- Go 言語に関する知識
「loop variables は同じ pointer を使うため，気をつけるべき」といったことや
「struct は embed したからといって親子関係ができるわけではないので気をつけるべき」といったことなどを学びました．
- Spannerに関する知識
Spanner がどのようなものかや，そのメリットやデメリット，使い方などを学びました．
- gRPC(gateway)に関する知識
gRPC(gateway)の使い方や，実装に必要な部分に関してはコードを読んで内部実装などを理解しました．
技術以外の面
- 大規模プロジェクトの動き方
「ABEMA」という大規模プロジェクトに携わることができたので，どのように大規模プロジェクトが進んでいくのかなどを経験することができました．
- 何でも話せる環境の重要さ
私が配属されたチームが気軽に話せる雰囲気だったり，トレーナーの方に気軽に質問することができたので，「何をすれば良いのか分からない」といった状況がなく，進捗を生むことができました．
このことから．何でも気軽に話せる環境(心理的安全性)がとても大事なことを改めて実感しました．
感想
新型コロナウイルスの影響でリモート勤務になってしまったことが残念でしたが，技術的なことを学んだだけではなく，今までしっかりとは考えてこなかった将来のキャリアについて考える良いきっかけにもなったインターンでした！
1ヶ月弱という期間でしたが，関わってくれた人事の方々やトレーナー，メンター，チームの方々，本当にありがとうございました！
CA Tech Accelで大きく成長した話
2020年11月〜2021年3月で，CyberAgent が企画する育成型プログラム CA Tech Accel に参加していました．
今回はこのプログラムの振り返りをしていこうと思います．
CA Tech Accelとは
CA Tech Accel (以下 CTA )とは，CyberAgent が企画する育成型プログラムです．
今回は，主に23卒向けエンジニア志望学生を対象にし，21卒の CyberAgent 内定者の方々とチームを組んで様々なことに取り組んでいきます．
サーバサイドエンジニアや web フロントエンドエンジニア，インフラエンジニアや iOS エンジニアなど様々な方が参加していました．
私は，サーバサイドエンジニアとして参加し，21卒内定者の方々3人と私の計4人でチームを組んでいました．
成長差分
CTAを通して様々なことに取り組んだ結果，大きく成長することができました．
様々なことを学びましたが，ここでは大きく5つの項目についての成長差分を取り上げます．
どれも未経験からのスタートで，Docker や CI についてはそもそもどのようなものであるのか，どのようなメリットがあるのかなどを全く知りませんでした．
しかし，CTA での取り組みが終わった今では，どれもある程度の知識を持ち，実際に活用することができるようになっています！
CTAで行ったこと
CTA では以下の流れのように様々なことに取り組みました．
基礎的な勉強
まずは，Go 言語を学ぶために A Tour of Go を行いました． goroutineやchannelなどを理解することが困難でしたが，内定者の方に質問することで大方理解することができました．
次に，入門 Docker を行いました． コンテナの概念などを理解することが困難でしたが，とりあえず手を動かしてみることで雰囲気をつかんでいきました．
また，上の2つと並行して，アーキテクチャの勉強もしていました． pospomeさんが書いた pospomeのサーバサイドアーキテクチャ を読みました． 代表的なレイヤ構造について，そのメリット・デメリットを参考コードとともにまとめてあり，非常に参考になりました．
チャットアプリ
基礎的な勉強の後，チャットアプリ作成に取り掛かりました．
大まかな内容は以下の通りです．
ユニットテストを書く際に，interface を用いた抽象化や DI などの重要性を感じました．
ソースコードはこちらです．
CA Tech Dojo
11月から学んできたもののアウトプットの場として，CyberAgent が企画するサーバサイド向けインターンである CA Tech Dojo に応募しました．
書類選考・面接の結果，インターンに参加させていただくことになりました．
CA Tech Dojo では，最優秀賞をいただくことができました！
詳しくは，以下の記事を見てください．
プロトスプリントリーグ
CA Tech Dojo で最優秀賞をいただいたことから，CyberAgent が企画するハッカソン型インターンであるプロトスプリントリーグに参加させていただくことになりました．
このインターンでは，クライアントサイド4人(C#, Unity)とサーバサイド1人(Go 言語)でチームを組み，ゲームを開発します．
私のチームでは，流れてくるブロックを盤面にうまく配置していくパズルゲームを作成しました．
パズルゲームとしての完成度を評価していただき，結果は3位でした！
TODOアプリ
CTA での集大成(?)として，クライアントサイド3人(Swift)とサーバサイド2人(Go 言語)でチームを組み，アプリ開発をすることになりました．
大まかな内容は以下の通りです．
私は，ユーザ認証周りとデプロイ周りを担当しました．
ユーザ認証は，jwt-goを用いて実装し，JWT に対する有名な攻撃手法(alg:none など)に注意しました．
また，デプロイは，コンテナに関する知識があまりにも足りないことをプロトスプリントリーグ中に自覚したので，GCP の Cloud Run を採用してコンテナ周りの勉強をしました．
CTAの良さ
CTA では，各々の興味があることや習得したい技術をもとにして，個別にカリキュラムを決めていきます．
それゆえ，勉強していく中で，前までは興味がなかったが今は興味があることをカリキュラムに入れたり，前までは興味あったが今は興味が薄れてきたことをカリキュラムから外したりなど，柔軟に学ぶことを変更することができます．
さらに，インフラで困ったらインフラチームのメンターの方に質問したりするなど，他のチームのメンターの方に質問することもできました．
(困っていることを slack で投げたら，それを見た他のチームのメンターの方が教えてくれたりもしました)
まとめ
CTA を通して大きく成長することができました！
今後は，実務経験を積むことや，知識のインプットやアウトプットをすることなどを通してさらに成長し，「頼られるエンジニア」に近づけるように努力していこうと考えています．
CTA のメンターをやってくださっていた21卒の CyberAgent 内定者の方々，様々な場面で手伝ってくれていた人事の方々など，本当にありがとうございました！
特に，私のチームメンターをしていただいていた@kume_ruさん，@konnyaku256さん，@u_chi_ha_ra_さん，ありがとうございました！！！！
CA Tech Dojoで最優秀賞を頂いた話
2021年2月15日〜2021年3月5日で，CyberAgent が企画するサーバサイド向け育成型インターンシップ CA Tech Dojo に参加していました．
そこで最優秀賞を頂きました！
今回はこのインターンの振り返りをしていこうと思います．
CA Tech Dojoの内容
このインターンでは，Go 言語を用いてゲーム API を開発しながら様々なことを学んでいきます．
基礎課題と発展課題が与えられていて，基礎課題が終わった人から発展課題に取り組んでいくような形になっています．
基礎課題では，与えられた API の仕様に沿った "とりあえず動く" API を作り，発展課題では，基礎課題で作った API を改善していきます．
目標
このインターンでは以下の3つのことを目標にしていました．
保守性の高いコードを書くこと
保守性の高いコードを書くために，アーキテクチャを改善したり，ユニットテストを書いたり，CI を回したり，ログ出力を考えたりしました．
その結果，「保守してもいい」と自分自身で思えるコードを書くことができました．
わからないところを放置しないこと
わからないところがあったとき，少なくとも自分自身が納得できるまで，調べたり，メンターの方々に質問していました．
その結果，より深い知識を吸収することができました．
他の Dojo 生と知見を共有し合うこと
私が学んだことを他の Dojo 生と共有するのはもちろんのこと，他の Dojo 生が学んでいることに対して，知見を共有していただいたりしていました．
例えば，同じチームでuber-go/zapを用いてログ機能を改善している人がいたので，ライブラリの使い方や，アクセスログとアプリケーションログの使い分け，ログレベルの使い分けなどについて教えていただきました．
また，インターンがない土曜日には，他のインターン生と知見を共有する LT 会を開き，知見を共有していました．
発展課題で行ったこと
私は，最初の3日間程度で基礎課題を終わらせ，残りの時間を発展課題に費やしました． 発展課題では，以下のような様々なことを行いました．
この中のいくつかを紹介していこうと思います．
アーキテクチャ(Clean Architecture)
Clean Architecture の概念を理解し，それを Go 言語の package 構成に落とし込み，実装しました．
package 構成を考えるのはかなり大変でしたが，メンターさんと何度も相談し，ある程度自分の中で納得できるような package 構成を考えることができました．
詳しくは，Qiita に記事を書いているのでもしよければ参考にしてください．
マスタデータのキャッシュ
ガチャの排出率やアイテムデータなどのマスタデータを毎回 DB から取得していると無駄が多くなってしまいます． マスタデータは頻繁に書き換わるものではないので，あらかじめ DB から取得しておいて，オンメモリにキャッシュしておくことで高速にマスタデータにアクセスすることができます．
私は，オンメモリにマスタデータを乗せるだけではなく，マスタデータが変わったときのために定期的にキャッシュを更新するような処理も書きました．
(今回のインターンでは時間的都合により以下のような処理を書いていますが，無駄が多く，改善した方が良い部分が多いです．)
まず，マスタデータを定期的に取得し，キャッシュを更新するような処理をgoroutineで走らせます．
しかし，このままでは，同一キャッシュに対して同一タイミングで書き込みと読み込みを行ってしまう可能性があるため，スレッド安全性を気にする必要があります．
そこで，次のような構成を考えます．
キャッシュの書き込みの前後と読み込み前後にLockをかけます．このようにすることで，書き込みと読み込みが同一タイミングで行われることを防ぐことができます． しかし，次のような問題点があります．
-
キャッシュの読み込み同士は同一タイミングで行なっても良いはずだが，それに対しても待ち時間が発生してしまう
-
キャッシュの書き込みをしている間は，読み込みは待機しているので，書き込み時間が長ければその分だけ待ち時間が発生してしまう
そこで，次のような構成に変えることで，問題点を解決しました．
まず，キャッシュの読み込みに対してはRLockを使うことで，読み込み同士で待ち時間が発生してしまうことを防ぎました．
次に，キャッシュへのポインタを用意し，裏で新しいキャッシュを作成し，ポインタ先を移し替えるときだけにLockをかけます． このようにすることで，キャッシュの書き込み時間が長くてもその分だけ待ち時間が発生してしまうことはなく，ポインタ先を移し替える時間だけに抑えることができました．
Redis の sorted set を用いたランキング機能
もともと MySQL を用いて SELECT ~ ORDER BY high_score DESC;とランキング取得していたものを，Redis も用いることで高速化しました．
詳しくは，Qiita に記事を書いているのでもしよければ参考にしてください．
CA Tech Dojoの良さ
メンターの方々のフィードバックが手厚い
このインターンでは，PR を出してメンターの方々にレビューをしていただくのですが，かなり細かい部分までレビューをしていただきました．
例えば，Go 言語におけるコメントの書き方のルールや，わかりやすい変数名の付け方，スライスのメモリ確保など，自分だけでは気づけないようなことまで指摘していただきました．
また，PR 以外にも，1日に1時間メンターさんが必ず zoom を繋いでくれる時間があり，技術的なことだけではなく，就活の相談や CyberAgent での実務のことなど様々なことについて話をすることができました．
また，インターン終了後には，人事の方から成績表をいただけるので，自分の良かった点・悪かった点を振り返ることができました．
発展課題の自由度が高い
基礎課題では，開発内容が決まっていますが，発展課題では，各自好きなことを行うことができます．したがって，自分の興味がある技術を深めることができます．
私は，上で挙げたようなことを主に行いましたが，gRPCを導入したり，Prometheusを用いて負荷分析を行なっている人，さらには，セキュリティに興味がありパケット解析をしている人などがいました．
まとめ
強いエンジニアが多く参加している中で，エンジニアとしての実務経験がほとんどない私が最優秀賞を取れたことはとても嬉しく，今後の自信にもなりました！ 3週間という間，様々なことで助けていただいたメンターの方々，人事の方々，インターンに参加していた方々，本当にありがとうございました！
