サイバーエージェントのおうち Kubernetes インターンに参加して（続き）
はじめに
こちらの記事は以前掲載したブログの続きになります。
簡単に説明いたしますと、2020年9月にサイバーエージェント主催の7days インフラ向け開発型インターン ONLINEというものに参加いたしました。参加前の準備や参加しての感想などは前の記事で書いたのでぜひご覧ください。
ここでは実際にインターンで何をやっていたのかをまとめていきたいと思います。
（順次更新予定）
挑戦したこと
私が取り組んだのは、
です。それぞれ説明していきたいと思います。
1.ラズパイを使ったクラスタ構築（物理）
参加者は最初にラズパイ三台を使ってk8sクラスタを作成します。詳細はこちら
作成したマイクラスタはこちら。約10cm * 10cm * 10cmの立方体になってます。サイズ感が可愛いですよね笑
2.hardwayでのk8sクラスタ構築（論理）
次にk8sが動くように論理構築になります。このパートも参考リポジトリをみて作業を進めました。私はhardwayというk8sをじっくり理解する方を選択して取り組みました。詳細はこちら
3.CNIpluginの交換
各自一通りクラスタを構築した後は独自の課題を設定して取り組みました。私はk8sの各コンポーネントをより深く知るためにhardwayのリポジトリを再読したりいくつか変更できる部分を交換しました。
その一つにCNIpluginがあります。参考リポジトリではtype: bridgeを使いルーティング情報を入力してpod間通信を確立していました。それをCalicoに変えてみました。
Calicoについて
こちらはCNIpluginの一つでネットワークとネットワークセキュリティを設定できるものです。詳しくはこちら
今回はCalicoを使ってpod間のネットワーク設定を導入しその後NetworkPolicyというpod間通信の制御を試してみました。 一通りクラスタができている状態だったのでそこからどのようにCNIpluginを換装するのかを調べるのが少し大変でした。換装の手順はこちらを参考にしています。
4.etcdの高速化
NetworkPolicyを試したことでpod間のトラフィックに興味を持ちました。そのことをメンターさんに相談するとサービスメッシュという考えを紹介していただきました。詳しくは次の章で説明します。サービスメッシュを導入する過程でetcdと通信する必要があるのですが、何度もタイムアウトエラーになってしまいました。
{"level":"warn","ts":"2020-09-29T04:57:06.254Z","caller":"clientv3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"endpoint://client-06270522-29c4-4880-9ee5-ea6115ecffd5/127.0.0.1:2379","attempt":0,"error":"rpc error: code = Unavailable desc = etcdserver: request timed out"}
そこでetcdを高速化するべく以下の改良を施しました。
- etcdをメモリ上に移動
- システム起動時と終了時にetcdのデータをSDカードに保存（永続化）
5.istioの導入
前章の作業を終えてetcdの通信速度が向上したのでistioの導入に進みました。
istioというのはサービスメッシュを実現するためのソフトウェアです。podの隣に「サイドカープロキシ」というものをつけpod間通信をサイドカー経由にすることでトラフィックを把握することができるようになります。俯瞰的に見るとメッシュ状に接続されていることからサービスメッシュという名前になったそうです。詳細はこちら
istioの公式サイトを参考に導入に進みました。作業上の注意点は、CPUアーキテクチャの違いを考慮する点です。マニフェストファイルのコンテナイメージはDockerHubから取得するのですがそれがarm64対応でないことが多く、確認する必要があります。affinifyの部分も確認しました。
次にistioの検証用環境をラズパイ上に構築しました。検証環境はistioの公式サイトにあるbookinfo applicationというサンプルアプリケーションを参考にしました。こちらもマニフェストファイルのコンテナイメージを確認しながら作業を進めました。インターン中にjavaのコンテナイメージをarm64対応にすることができなかったのでレビューページは作成できませんでしたが、それ以外の部分はなんとか作成することができました。
下図は作成したアーキテクチャ図です。
下図はkialiで捉えたトラフィック図です。トラフィック全体がスクリーンに入りきらなかったので恐縮ですが、通信できている部分は緑になっています。
LT会
本インターンではメンターさんによるLT会が企画されていることもありました。メディア、広告、ゲームの三つの事業から社員さんが一人ずつ発表されて日頃の業務内容や扱っている技術、最近やっていることなどざっくばらんに聞くことができました。社外秘が多いので詳細はお伝えできないのですが、ざっと何をお話しされていたのかをまとめました。
メディア
メディア事業部ではパブリッククラウドサービス（AWS, GCP）だけでなく自社で作ったプライベートクラウドサービス（Cycloud）を実際の事業で活用しています。今回のLT会ではCycloudの中身や取り組んでいることを教えて頂きました。最後にはエキシビジョンということでDockerの「マルチCPUアーキテクチャサポート」のイメージビルドについて説明して頂きました。
広告
サイバーエージェントにはSIA（Strategic Infrastructure Agency）というAI事業本部向けにインフラを整備する組織があります。そこではプライベートクラウド、AKE（Adtech Container Engine）、GPUaaSなどのインフラ基盤の保守管理を担当しています。今回は2016年後半にAdtech Studioで検証開始され、現在AI事業本部で運用されているAKEについて説明して頂きました。今年のCNDT2020では監視基盤についての発表がありました。
ゲーム
サイバーエージェントにはゲームとエンターテイメント事業に携わる子会社が所属している組織SGEがあります。 実態は九つの子会社からなるもので各社の強みを生かした開発とノウハウの共有が目的となっています。ゲームを開発する上でパブリッククラウドサービスを利用しているのですがどのように利用しているのかや、各子会社ごとのインフラの違いなどを教えていただきました。
インターンを終えて
ここからは自戒の念を込めて反省を書きたいと思います。
力量を常に把握すること
始まる前から予想できたことでしたがやりたいことに対して時間が足りなかったです。そんな状況で必要なのは実現可能な計画を立ててそれをしっかりこなすことだと学びました。
元々インターン期間中に k8s 上で自作アプリを動かすことを目標にしていましたがクラスタ作成で二日間かかりメンターさんから難しいと指摘されました。そこで k8s の理解に専念するという方針転換をしました。クラスタ完成の時点では「なんとかなるだろう」と楽観視していたのでこの一連の再考を通して自分の作業管理の甘さを痛感しました。作業計画を立てるためには、自分の力量（技術力、理解までにかかる時間）の把握が必要です。まずは力量の把握からはじめていき、今後現実味のある計画を立てれるよう頑張りたいと思います。
基礎知識は大切
これはあらゆるところで言われていますが、このインターンでも痛感しました。今回 k8s を扱うにあたって様々な知識が要求されました。しかし一番必要なのは初歩的な理解であると痛感しました。
設定段階でもそうですが私が痛感したのはトラブルシューティングの時です。自分だけでは解決できずメンターさんに質問すると、瞬時に必要なログと現在の設定状況を問われました。その後指示された作業をして解決することができたのですが、この解決力が自分には足りないと感じました。
k8s は複雑な処理を「いい感じ」にこなしてくれる便利な技術ですが、エラーが起きた時に対応が難しいと感じています。しかし k8s はブラックボックスではなく既存の技術の上にできています。つまり基盤技術をしっかり理解できれば対応可能であると身を以て経験しました。これからは新しい技術を知るだけでなくその技術の元になっている概念や技術を理解していこうと思いました。
インターンで取り組んだことをしっかりと自分の血肉にして今後も精進していきたいと思います。ありがとうございました！
