しょ〜うぃん広場

おもにTech系なブログ、ときどき個人的なブログ

「Kubernetesで実践するクラウドネイティブDevOps」を読んでみた

LAPRASでは、AWSのEKSをつかってインフラを管理しているのだが、今後自分がインフラの面倒をメインで見ていくことになったので、社内のインフラエンジニアにおすすめの本を聞いてみた。 「Kubernetesで実践するクラウドネイティブDevOps」がおすすめとのことだったので読んでみたところ、とても良い本だったので紹介しようと思う。

ちなみに LAPRAS夏の自由研究リレー なるものをLAPRASメンバーでやっていて、これはその2日目の記事。 本を読むだけで研究なのかというツッコミはあるが、きっとこの後も面白い記事が続くと思うのでチェックしてみて欲しい。1日目の $ docker pull$ docker run を自作してみる話も面白かったよ。

moro-archive.hatenablog.com

本題に戻り、、

まず結論から

基礎から運用まで実践的な話が多く、インフラエンジニアとして現場でk8sの運用をしていく人にはかなり向いている本だと感じた。当然ではあるのだけど、コンテナについての基礎的な話はあまり書かれていないので、そこはある程度知識を持った上で臨む必要がある。中級者向けの本という感じ。

自分の場合は、もともとアプリケーションエンジニアとして、k8sのdeploymentを少し書き変えたりpodに入って作業することもあったので、k8sの目に見えやすい部分はざっくり理解した状態でこの本を読み始めた。その結果、曖昧に理解していた部分の復習に加えて、知らなかった部分の補完ができてすごく理解が深まったので、同じ立場の人にはおすすめしたい本である。

1~3章

k8sを取り巻く環境についてや、どのクラウドインフラプラットフォームのマネージドサービスがおすすめかなどが書かれている。本ではGKEイチオシと書かれているが、社内でAWSのEKSを使っていてもいままであまり不便を感じたことがない。自分で調べたところ、いずれのマネージドサービスでもk8sの最新バージョンから2世代ぐらい遅れたバージョンから利用可能という状況はあまり変わらないので、料金体系以外はあまり気にしなくてもいいのかなと思っている。

4~8章

k8sを使う上で最低限これだけは知っておきたいオブジェクトの操作だったり、リソース管理方法について書かれている。文中には「この本を読んでいるだけでは深く理解できないので、実際に手元のPCでk8sを動かしながら読み進めていくと良い」という旨が書かれていて、技術の勉強するにあたっては当然のことであるが、それをきちんと明記してくれるあたりいい本だなと思ったりした。

シェルのエイリアスはこうするのがいいよ

alias k=kubectl
alias kg=kubectl get
alias kgdep=kubectl get deployment
alias ksys=kubectl --namespace=kube-system
alias kd=kubectl describe

とまで具体的に書かれていることからも、どこまで"実践"を大事にしている本かを理解することができる。

9~16章

9章以降は少しずつ発展的な内容になっていくので、運用者以外は軽く流し読みしても良い内容なのかも知れない。もちろん有用なことは多く書かれているので時間があるなら読むに越したことはないが。

環境変数、セキュリティ、CI/CD、デプロイ戦略、開発環境、メトリクスなど話題は多岐にわたり、すぐに必要にはならない知識もあるので、一度軽く読んでおいて、必要になったら深く読み返すような使い方に向いていそうだと思った。

その中でも15章の"オブザーバビリティ"という概念は良かった。日本語にすると"可観測性"になるが、どこまで観測可能にしておくかということである。 例えば、k8s自身による監視機能や内部のメトリクスには異常がないのに、ユーザがWebサービスを見れなくなる原因として

  • DNSレコードの誤り
  • ネットワーク分断
  • パケットロス
  • ルータの設定ミス
  • ファイアウォールのルールの欠落または誤り
  • クラウドプロバイダの機能停止

などが考えられる。つまりk8sによる監視だけでは不十分であり、外形監視の仕組みを取り入れるなどしてオブザーバビリティを高める必要がある。

また、コンテナが標準の世界ではいつコンテナが終了するかもわからないので、ログのライフサイクルについても考え方の変化が必要で、ログアグリゲーターが各コンテナから抽出してコンテナの外に保存しておくことが必要になる。 オブザーバビリティに取り組むことで、事実とフィードバックに基づくエンジニアリングのチーム文化へと移行することができるという話もよかった。

まとめ

上述のように、基礎から発展的な内容まで網羅されていて、必要に応じてリファレンスとしても見返せる本である。リファレンスとして使える本は一般的に分厚くなりがちだが、350ページ程にまとまっていて、10時間弱で読み終えることができた。(リファレンスとして使えると言っても、この本だけあれば完璧というほどの情報量はないので、まずこの本でツールの選択肢とその特性を理解した上で、詳細はそれぞれのツールのドキュメントを読むことになると思う)

前任のスーパーインフラエンジニアがきちんと設計/運用してくれていたおかげで、自分自身はこの本を読み終えても「これやったらもっと良くなりそうじゃん!」的な要素は少なかったが、この本の内容を身に着けておけば中規模〜大規模サービスまでは面倒見れるようになると思うので超おすすめの一冊である。

Oxygen Not Included 後半の攻略法

Oxygen Not Included はアーリーアクセスの頃に100時間ぐらいやっていて、今年7月に正式リリースされてからさらに100時間ぐらいやっていた。 アーリーアクセスの頃はロケット打ち上げ始めるあたりで打ち上げ方がわからなくて諦めて放置してしまったのだけど、正式版リリースされたということで、そのあたりのUIも改善されているかなーと期待して2週間前ぐらいからもう一度最初からやり始めた。

ぼくの友人もこんな感じで言っているので、やったことがない人はぜひやってみてほしい。

極寒の惑星ライムで、楽勝モードで始めて、ロケット180000kmまで飛ばして、モニュメントも立てて実質クリアしたので後半の攻略法というかTipsを書いていこうと思う。 180000kmまでロケット飛ばす実績解除が0.1%のユーザが達成。らしいので、割とみんな中盤辺りまでしかやっていないように感じる。(気持ちはわかる)

書いていくTipsの順番は適当。 自分でやっていきながら学習していきたい人には向いていないTipsかもしれないのでそういう人はそっ閉じしてほしい。

宇宙周辺の鉱夫ロボットがオーバーヒートする問題

宇宙付近は真空に近いので鋼鉄で作っていると、鉱夫ロボットが稼働している間に蓄積される熱を排出する場所がなくなってオーバーヒートしてしまう。 対策としては石膏ボードで背景を覆って、適当な気体を充満させて熱を逃がす方法があるがそれは気体管理が面倒なので、早めにロケットに貨物ベイを載せてニオブを採取してオーバーヒート温度+900℃のテルミウムを作ると良い。テルミウムで鉱夫ロボットを作れば真空空間で稼働させてもオーバーヒートしないので安心。

ソーラーパネルのオーバーヒート問題

ソーラーパネルはガラスでしか作成できないため、最後までオーバーヒート温度が75℃のまま。ソーラーパネルの上にシェルタードアを作って隕石感知後にシェルター閉める作戦だと、シェルターが開いて鉱夫ロボットが採掘している間に砂岩の熱がソーラーパネルに移ってしまう。それで徐々にソーラーパネルが加熱されていきオーバーヒートしてしまう。 解決方法としてはソーラーパネルの上に窓タイルを敷くこと。窓タイルは光を通すので上にあってもソーラーパネルは発電できるし、上から表土が落ちてきても窓タイルが受けてくれるのでソーラーパネルには熱が移らなくて済む。

火山がうまく活用できない問題

火山の天然の力を使って蒸気タービンで発電できないかなーと考えるけど意外と難しかったりする。火山周辺が熱すぎて、その熱が蒸気タービンの上まで来てしまい蒸気タービンが100℃以上になることで動かなくなるからだ。(蒸気を水に戻すために蒸気タービンは100℃以下である必要がある) 対策としては、セラミックか断熱材で断熱タイルを作ると熱を火山周辺に閉じ込められる。断熱材は惑星からニオブを採取してきて作る。僕は早めに断熱材断熱タイルを作ってしまったので、セラミック断熱タイルの性能がわかっていないが、セラミック断熱タイルでも2,3マスつなげて断熱材を配置すればかなりの熱を抑え込めると思う。

蒸気タービン側が熱くなりすぎる問題は、適当に冷やした液体を輻射パイプでタービン周辺に流してあげればタービンは冷える。

ロケットどこまで飛ぶのかわからない問題

https://oni-assistant.com/tools/rocketcalculator のサイトでどれだけ燃料積めば良いのか計算できるが、少し値に誤差がある気がする。 最後180000km飛ばすときは、液体水素4500Lとオキシライド4072kgがあれば良い。と計算できるが、実際にはオキシライド4500kgぐらいにしないと届かなかった。 上のサイトは目安程度に使うと良さそう。

液体水素生成方法

40000kmぐらいまで飛ばすとフラーレンが痕跡量存在する惑星が見つかるはず。1,2%フラーレンが存在してる惑星があるのではと思っていろいろロケット飛ばしたけど、痕跡量以上の量が存在している惑星はなかった。 フラーレンが手に入ると超冷却材が作れるようになる。 多分自分は500kgぐらい作ったけど、多分200kgぐらいあれば液体水素を作るのには十分だと思う。

液体水素が液体である温度は-259.2℃から-252.2℃の7℃の間しかないので、温度調節が難しい。 -257℃以上の温度だったら液体クーラーを通して、それ以下だったらクーラー通さずに通過するような液体回路を作って、輻射パイプで気体水素がある空間を冷やせばうまくいく。液体水素を吸った後に気化してパイプにダメージが入ることを心配してしまうが、セラミック製の断熱パイプでもそこそこ長い距離移動できる。温度的には液体水素でいられる温度を上回っていて、本来なら気体になってしまう温度でもなぜかパイプの中で液体でいてくれる。 ロケットの液体燃料タンクに入れてしまえば温度がほぼ一定に保たれるので、なるべきロケットに近いところで液体水素を生成すれば断熱材を使った断熱パイプを使わなくても問題ない。(断熱材の断熱パイプが必須になるとイソレジンの収集にかなり時間がかかるのでゲームバランスの調整が入っている気もする)

鋼鉄足りない問題

ロケットを作り始める頃になると鋼鉄がたくさん必要になる。特にテルミウムが手に入る前は鋼鉄製の設備がオーバーヒートしてその修理にまた鋼鉄が…とかなる。 鋼鉄の材料になる石灰の入手が難しくて苦労する。 まずは化石から石灰をつくる方法。化石100kgから石灰5kgしか作れないので効率が悪く見えるが、一番簡単に生成できるのでマップ上にある化石はすべて掘り尽くす覚悟で探しに行くのが良い。

それだけでは足りない場合には、ポークシェルの脱皮した殻か動物の卵の殻から作ることになる。 ポークシェルは意外と飼育が難しくて、食料の確保も難しいし、卵が近くにあると突然怒り出してこちらを攻撃してくるので普通に死にそうになる。 ポークシェルの飼育は浄水器2,3台ぐらいを対象にして、排出される汚染土を自動輸送して給餌器に入れると良い。そこを自動化することで人間の手間も省けるし、ポークシェルが怒っても攻撃される可能性が低くなる。

あとはポークシェルに限らず適当な動物の卵を壊せば卵の殻が手に入る。自分の場合は最大サイズの部屋3つぐらいで一番手頃なハッチを育てて、ひたすら生まれてくる卵を割っていた。(割りすぎると全員いなくなるので、ハッチを生存数で自動回路を組んで孵卵器を有効にしたりしてた) 卵の殻は石灰にして、卵の中身は腐敗する環境下に置かれた食糧保管庫に入れておいて腐らせるとポークシェルの餌になって便利。(人間はもっと士気があがる食べ物を食べているはずだし)

AtCoder Beginner Contest 136

今日は会社でAtCoder勉強会と称して、6人ぐらいでBeginner Contest 136を解いた。 本当は100分でやるコンテストだけど、80分に短縮して、終わった後40分を感想戦に使う合計2時間の勉強会形式で実施した。

結果は80分でA~D問題が解けた。Dは時間ギリギリという感じ。

このコンテストの順位表を見ていると、E問題が解けて青色。Dまでだと水色以下という感じだった。 D問題が解けて喜んでいたんだけど、E問題までできるようにならないとだめであった。

同僚が蟻本を持ってきてザッと目を通したのだけど、身につけるべき知識がレベル別にまとまっていてとても良さそうな本だった。 もうしばらくして問題の難易度の傾向がつかめたら蟻本を読んで先に知識をつけるのが良さそうという感じがした。

AtCoder Beginner Contest 125

Beginner Contest 125 まではA~Dまでの4問題だったようだ。 6問題ある前提で、D問題まで確実に解けて、E問題を半分ぐらい。と考えていたが、6問になったのは意外と最近なことがわかってしまった。

これからどうやって練習していこうかちょっと迷うが、とりあえず今回はBとC問題を解いてみて難易度を確認する。

B問題

思ったより簡単だった、6問ある場合のBとC問題の間でB寄り。ぐらいの難易度だった。 一発AC

C問題

最初に思った解法だとTLEだったので、もう少し計算量を減らすようにしたらACだった。 O(N)を意識できるようになってきた感じがする。

大体最初に思いつく解法はO(N2)な事が多くて、そこからどう計算量を減らせるかなーって考えることが多い。

ちなみにこの問題の解説を読んだけど何を言っているのかわからなくて難しかった。

自分は解法はこう。 1. 与えられたAのなかで2番目に小さい数字を取り出す 1. その数字でAの要素の中で割り切れない数字が1つ以下になるかどうか確かめる。 1. 1つ以下になればその数字が答え。2つ以上あればそこから1減らした値でまた(2)を行う。

1つだけ数字を変えることができるので、1つ割り切れないものがあってもその数字を変えれば良いという考え。 最初に一番小さいものではなくて、小さいものから2番目を取っているのは一番小さい数字を変更する可能性があるため。

感想

家に帰ってきた時間が遅くて、時間的にD問題を解く時間がなかったけど、30分でBとCが解けたので良かったと思う。 と書いたところで、このコンテストの順位を見に行ったのだけど、40分でA~Cを解いている人は水色かそれ以下のランキングの人だった。 青色を取るにはこのコンテストでD問題まで解かないといけないらしい。

次回はこの問題のD問題を解いてみようと思う。

AtCoder Beginner Contest 126

C問題

問題文読んでそのまま書いたらACだった

D問題

問題文読んでそのまま書いたらTLEだった。

親の頂点からの距離が偶数か奇数で子の頂点の色が決まることはわかったが、親から順番に子を辿っていって色判定しているとTLEになる。 原因は辺の情報を[1, 2] のようなリストのまま持っていて、親が決まったと時に、子を探すのにリストの1,2つめの要素を両方見ていかないと行けなくて、根から頂点を辿っていくときの効率が悪かった。

children_of = [[] for _ in range(N)]
children_of[1].append(2)
children_of[2].append(1)

のように、双方向で辺の情報を持っておいて、ある頂点につながっている頂点をO(1)で出せる状態にしたらACした。

AtCoder Beginner Contest 137

今回は青色までということにしているので、C++は使わずにPython3で頑張っていこうと思う。 仕事でPython書いているので一番すらすらかける。 頭で考えたアルゴリズムをすいすい実装できないのがイライラしてやめたくなりそうなので、一番かける言語でやっていく。

青色に到達するまでに解かないといけない問題を見てみると、大体だれかがPython3でACを出しているのでできるはず。

C問題

愚直に書いたらTLEになった。 C問題は大体そのまま書いたらACになることが多いので、おーって思いながら書き直す。

結局AC出すまでに30分弱ぐらいかかってしまって、ちょっとこのC問題は難しかったように感じる。 自力でできた。

D問題

この考え方だとO(N2)になるなーどうするんだろう…って30分ぐらい悩んでコード書く前に解答を見た。 ソートして最大値を取り出すところはO(N)かかると思っていたけど、優先度キューというものを使えばO(logN)でできるらしい。

Pythonだと heapq ライブラリが提供されている。 手元で実行時間比較してみた。

lst = [random.randint(1, 10000) for i in range(1000000)]

time sorted(lst)[0]
435 ms

time min(lst)
18.3 ms

time heappop(lst)  # 詰めるところは省略
26.9 µs

heapq 取り出すのめちゃくちゃ速い。 僕の理解だと詰めているときにソートしているはずなので、heapqの取り出しはO(1)でできているはず。

ただ詰めるところまで時間を考えるとmin()しても同じ

In [1]: def _heap_pop():
    ...:     for i in range(1000000):
    ...:         heappush(lt, random.randint(1, 10000))
    ...:     heappop(lt)
    ...:

In [2]: time _heap_pop()
CPU times: user 1.54 s, sys: 22.8 ms, total: 1.56 s
Wall time: 1.56 s
-----------
In [3]: def _min():
    ...:     lst = [random.randint(1, 10000) for i in range(1000000)]
    ...:     min(lst)
    ...:

In [4]: time _min()
CPU times: user 1.43 s, sys: 21.5 ms, total: 1.45 s
Wall time: 1.45 s

つまり繰り返しリストから最大/最小値を取り出すときには heapq を使うとよさそう。 1回だけなら min(), max() でも変わらないようだ。

heapq のTipsとして、最大値を取り出したいときの方法がある。 heapq はpopで最小値しか取り出すことができないので、リストの中の最大値をとることはできない。 最大値がほしいときには heappush する時に要素に -1 を掛けて入れて、取り出した後に -1 をまた掛けると、最大値が取り出せる。

これは他の人の解答をみて学んだのだけど、頭いいなーと思った。

AtCoderを始めてみる

DMM英会話は56日目で終わってしまった。 はじめの頃は成長を感じていたのだけど、50日ぐらいやると大体慣れてきてボトルネックが語彙力になってきた。 これ以上DMM英会話続けてもコスパ悪いなー、単語帳やるか〜って思っている間に英語学習のモチベーションが下がって英語勉強は終焉を迎えた。

そのあとは進捗50%ぐらいで半年ぐらい放置されていた Switch のゼルダをクリアしたり、Bloons TD 6 というぼくが中学生ぐらいのときに始まったシリーズのタワーディフェンスゲームをやったり、Switch で FF XII THE ZODIAC AGE をやったりしていた。

ゲームも同じジャンルをやっていると飽きてしまうので、アクションRPG(?)からTDからRPGからいろいろやる。 あとは Automachef っていう食品工場を自動化するゲームもちょっとやった。Factorio に1000時間近く溶かした自分なら楽しめるかと思ったけど、操作性が良くなくて途中で飽きた。

先週ふとメールボックスをみたらAtCoderの大会開催メールが来ていることに気づいて、久しぶりにやるかーと思って2年振りぐらいに挑戦してみたら意外と面白かったので、AtCoderちょっと力入れてやってみるか!という気持ちになっている。 これもまたゆっくりやっているとすぐに飽きてしまうので、10月末までの70日ぐらいで青色(上位5~6%ぐらい)に到達することを目標に短期決戦でやっていこうと思う。

ざっと見た感じBeginnerコンテストのD問題は確実に解答、E問題は半分ぐらいの確率で解ければ青色にギリギリ入れるラインのように見えるので、それを目標にC~E問題を中心に解いていく。 現状はC問題はほぼ確実に解けて、Dはう〜んできそうだけどできない。という感じ。

DMMのときみたいに、解いた問題をここに垂れ流していこうと思う。 過去のBeginnerコンテストのC~E問題が中心だと思うけど。