@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

202207 振り返り

外を少し歩くだけでも分かるくらいの汗をかく。
ご飯を食べに行くのも暑くて嫌になることがあるがアイスや冷凍食品をたくさん食べているので体重は順調である。
年々暑くなってる気がするのだけど、来年はもっと暑くなるのかと思うと今からげんなりする。

べんきょうかい

今月も何も参加しなかった。
本も技術書をあまり読んでないので最近は本当に勉強が足りてないなと痛感している。
来月こそは。

ほん

コミックをいつも通りたくさん読んだ。
月末には小説がたくさん出ていることに気がつきたくさん買ったのをまとめて読んだ。
まだ買った小説はたくさんあるけど来月は実家に帰る時間があるので小説ではなく技術書読むぞ。

えいが

実写版を2つ観てきた。
他にも観ようと思ったのだが暑くて外に出るのを断念することが多かった。

ぶろぐ

いつも通り本を読んだので。
来月は夏休みもあるのでもう少し書けるような本を読みたいな。

link.medium.com

202206 振り返り

暑い。
暑くて外を歩くスマホゲームが全然すすめることができない。
このままでは歩数は減る一方なのに、体重と積ん読の数だけどんどん増えていってしまう。
せめて外に出てないのだから本だけでも減らしたい。

べんきょうかい

すっかりあることを忘れてしまっていた。キーノートだけ見たので、ビデオが公開されたらどんどん見ていきたい。
最近勉強会への参加もめっきり減ってしまったな。

ほん

今月も小説をいくつか読めた。いくつかブログを書きそうだなと思う本を買ったのだが読むことができなかった。
暑くなってきて外に出るのも億劫になってきたので家に籠もる時間を読書にあてていきたいな。

えいが

気がついたら1ヶ月が終わっていて見に行っている暇がなかった。
ドラゴンボールは面白かったな。シン・ウルトラマンはあと1回位は観に行きそう。

202205 振り返り

先月に頂いたビールを順調に消費している。
美味しくいただこうと毎日飲んでいる。その際に本を読もうと思いながら最近は紹介されたYouTube を見ることが増えている。

YouTube で紹介される本がどれも面白そうで本が本を呼び、家の本がどんどん増えている。でも面白そうな本ばかりなのでしょうがない。ただし、絶版になっている本もあるのが辛い。
図書館に行くことも考えないとな。

べんきょうかい

いくつか申し込んでいたけど流し見になってしまった。
最近新しいこと学べてないのでちょっと不安になってきている。

ほん

今月は技術書もそうだけど小説を読むことができた。
SF 小説はやはり好きらしい。これでストックが切れたのでまた何か面白そうな小説を見かけたら買って置こうと思う。
ただ、小説よりも溜まっている技術書を先に読むのを頑張るんだ。。。

えいが

シン・ウルトラマン良かった。普通ので見たあとにIMAX 版を見に行ってしまった。
シン・ゴジラのときにも何回も見に行ったことを思い出したのでまた行くんだろうなと思っている。

ぶろぐ

GW で引きこもる時間があったので溜まっている本を何冊か読んでみた。
いつもどおりその中で気になった内容について書いてみた。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

link.medium.com

「Amazon Web Services クラウドデザインパターン」を読んだ

AWS の設計パターンを勉強しようと買って積んであった本に手を出した。
読んだのは以下の3冊になる。

パターンとしては以下のパターンが紹介されている。

  • 基本パターン
  • 可用性向上パターン
  • 動的コンテンツの処理パターン
  • 静的コンテンツの処理パターン
  • データアップロードのパターン
  • リレーショナルデータベースのパターン
  • 非同期処理/バッチ処理のパターン
  • 運用保守のパターン
  • ネットワークのパターン

それぞれのパターンの中で設計パターンがいくつか紹介されており、合計で57種類の設計パターンが紹介されている。
そして、実装ガイドの方や、定番業務システムパターン設計ガイドの方ではこの57種類のパターンの組み合わせでさまざまな状態に対応するシステムが設計されている。パターンとしては処理するものに対してや処理する場所などについて別れているので、1つのシステムの中で必要な箇所に必要な設計パターンを当てはめていくのが良いと思う。

まとめ

  • 57個に設計パターンがまとめられているため覚えやすい
  • パターンの組み合わせでシステムの作成ができるのでそれぞれの特性を覚えておきたい
  • パターンごとに使うサービスについてまとめておきたい

「インフラデザインパターン」を読んだ

インフラの勉強をしておくのにまずは世の中の標準的な知識を身に着けようと思っていて読みたかった本。オンプレでもクラウドでも知っておいて損にはならない知識だろうと思い読んでみた。

第1章 インフラデザインパターンとは何か
第2章 可用性要件の実現策
第3章 セキュリティ要件の実現策
第4章 性能・拡張性要件の実現策
第5章 運用・保守性要件の実現策
第6章 インフラ構成の設計方式
第7章 クラウドコンピューティングを使った実現策
第8章 [実践]パターンベース設計

本書は著者の方々が仕事のなかで構築したり、調査してきた内容からインフラデザインパターンとしてまとめた内容が紹介されている。数としては127ものデザインパターンが紹介されている。それぞれのデザインパターンが図付きで紹介されており、メリット・デメリットなどがわかりやすく紹介されている。本書の中では可用性、性能・拡張性、セキュリティ、運用・保守性といった非機能要件別やクラウドコンピューティング、ネットワーク構成、ストレージ構成などインフラ構成別にまとめられている。

できることだけがまとめられているのではなく、できないことや留意点もまとまっているのも良かった。やろうとしてもできないことがあるなどわかるのは読んでいて良い経験だった。

Web/AP サーバやDB サーバの設計方式とかは考えたことがあったがそれ以外にも、LAN、WAN、インターネット接続やデータバックアップの可用性などについても設計パターンが紹介されている。これらのパターンを組み合わせることでのインフラ構成の設計が例として紹介されているので、どのようにパターンを使って考えれば良いかの例としてわかりやすかった。

また、クラウドのメリットを享受しながらインフラを構築するための章などもあり、覚えるべき知識や考えなきゃいけないことはたくさんあるんだなと再認識した。それぞれの環境の良い点を組み合わせてうまいインフラを構築できるように今後も勉強を続けていきたいと思った。

まとめ

  • パターン化されているので説明できるように身に着けたいと思う
  • パターンを使うことで考えるべきことに集中して考えれるようになりたい
  • 下の本を今後は読む予定なのでクラウドの知識を更につけていくぞ

「カオスエンジニアリング入門」を読んだ

本屋をぶらついていたらタイトルが目に留まったので読んでみることにした。
目次は以下。

CHAPTER 01 : カオスエンジニアリング誕生の背景
CHAPTER 02 : カオスエンジニアリングの概要
CHAPTER 03 : カオスエンジニアリングの実践
CHAPTER 04 : カオスエンジニアリングツール
CHAPTER 05 : CI/CDとカオスエンジニアリング
CHAPTER 06 : セキュリティとカオスエンジニアリング
CHAPTER 07 : 海外および国内におけるカオスエンジニアリング
CHAPTER 08 : エンタープライズへの導入に向けて

カオスエンジニアリングは名前は聞くけどやったこともないし、何かを読んだこともなかったので基本的なことから書かれているのがとても助かった。

カオスエンジニアリングの誕生はシステム全体が複雑化し、そのような状況下の中で障害箇所をすべて把握、対策することは困難なため、あえて障害を起こすして脆弱性を検証していくために考えられたというのが面白い。障害を前提として対策を日々考えていくのは対応力も身につきそうだなと思った。

以下のNetflix が提案しているカオスエンジニアリングの原則が紹介されている。 principlesofchaos.org

ここに書かれている原則は以下の5つ。

  1. 影響範囲を局所化する(Minimize Blast Radius)
  2. 定常状態における振る舞いの仮説を立てる(Build a Hypothesis around Steady State Behavior)
  3. 実世界の事象は多様である(Vary Real-world Events)
  4. 本番環境で検証を実行する(Run Experiments in Production)
  5. 継続的に実行する検証の自動化(Automate Experiments to Run Continuously)

カオスエンジニアリングを行うためのシステムとしては回復性と可観測性、自動化が高いシステムであることが必須と言っても良さそうだ。故障しないのではなくすぐに回復できるようなシステム、システムの状態を監視できる仕組み、継続的にテストを行うために低負荷でシステムを復旧できるような自動化。これらが最低限揃っていることで初めてカオスエンジニアリングを行うことができそう。どれか一つでもないとそもそもシステムダウンしたり、システムが落ちているかわからなかったり、作業者が高負荷になってしまうなどの別の問題が出てしまうのだろう。
この中で可観測性はモニタリングの代わりになるものではなく補完し合うものと紹介がされている。そのため必要なのは、ロギング・メトリクス・トレースといった3種類のデータを取得・活用できるようにする必要性が説明されている。このあたりはカオスエンジニアリングをしないとしても取得しておくべきものを定義しておくのが重要だなと思った。

後半はカオスエンジニアリングを行うためのツールの紹介、また実際にツールを用いてのCI/CD の組み立て方が紹介されている。自分でも少し試してみることができるのでわかりやすかった。
その後はセキュリティ、人・プロセスに対する導入などについても書かれているがこのあたりは知識が足りていないので読むだけになってしまった。もう少し勉強をしてから再度読み直してみたいと思う。

CHAPTER 07 では国内外の発表についてまとめられていてとても助かった。国内でもいくつもの会社が発表しており、見たことない資料もたくさんあったので紹介されているリンクを順に読んでみようと思った。

まとめ

  • やってないけど興味があるレベルで読むのにはちょうどよい内容だった
  • 自分のシステムで実行するかはともかく、回復性と可観測性でシステムを見直してみたいと思った
  • このあとオライリー本も出るようなのでそれまでにもう少し勉強をしておこうと思う

「システム運用アンチパターン」を読んだ

運用はずっとやっていて興味のある分野のひとつなので読んだ。
目次は以下。

1章 DevOpsを構成するもの
2章 パターナリスト症候群
3章 盲目状態での運用
4章 情報ではなくデータ
5章 最後の味付けとしての品質
6章 アラート疲れ
7章 空の道具箱
8章 業務時間外のデプロイ
9章 せっかくのインシデントを無駄にする
10章 情報のため込み:ブレントだけが知っている
11章 命じられた文化
12章 多すぎる尺度

DevOps の話なので文化を変えようという話が多い気がする。まずはDevOps の説明から始まっている。
1章のまとめには「DevOpsの真の目的は仕事に対する見方や、異なるチームにまたがるタスクの関係を再定義すること」や「この本を読んでいる皆さんの多くはエンジニアであり具体的な行動に着目しがちでしょう。本書の前半では、皆さんの組織が直面している可能性の高い問題を例に挙げ、その解決に向けた具体的なアプローチをいくつか紹介します。その際にも企業文化がその状況に与えている影響を強調します」とあるように文化を変える、文化を共有することが必要だと説明されている。

文化を変えようとするとエンジニアだけではできないことが多々あると思う。しかしそれだけではなく本書では現場のエンジニアから始めれることも書かれている。
いくつかを例に上げると

  • ログが適切なログレベルででていること、ログには文脈を含める
  • データとしてメトリスクスを取るのではなく見る人のことを考えたダッシュボードを作成する
  • テストのグループ化、継続的デリバリ
  • 運用の自動化は設計プロセスのできるだけ早い段階で検討する
  • インシデントが起こったらポストモーテムを実施する
  • ポストモーテムをドキュメント化し、それぞれの対象者ごとに節を設けよう
  • すべてのポストモーテムを同一の場所で共有する
  • 標準的なドキュメントの代わりに、学習のための習慣をつけよう

学習についてやドキュメント作成・管理について、またログの設計やダッシュボードの作成などはエンジニアだけで変更をすることができると思う。ポストモーテムも行って、共有やドキュメントの管理はできるだろう。このあたりのできることからコツコツとやっていきたいなと思う。

エンジニアだけでできないことで人材採用や、承認プロセス、アラート作業への補償など。このあたりはエンジニアだけでどうにもできないので上司とかも交えて話をしていきたいなと思った。

まとめ

  • できることからメンバとやってみようと思った
  • 文化を形成するために言葉遣いとか今後気をつけよ
  • 本を信じるだけではなく経験からの知識も大事にしていこうと思う