Open34

O'Reilly Online Learningの積読を解消

hmatui66hmatui66

このスクラップは?

福利厚生で O'Reilly Online Learning 使えるが、積読がなかなか消化されないので、消化のために1日 15分で積読の1章を読んで3行サマリを書いていく。 1 分読んで、なんでもいいのでメモる。

hmatui66hmatui66
hmatui66hmatui66

Chapter 1: Introduction to Monitoring

  • ソフトウェアシステムの監視の重要性
  • 監視のユースケース
  • popular な監視ツールと監視に関わる概念と用語の紹介
hmatui66hmatui66

Chapter 2: Deploying the Datadog Agent

  • Datadog Agent は Cloud, OS 上の環境の両方を監視できる
  • Datadog Agent の主要なコンポーネント: Collector(15秒ごとにメトリックを収集), Forwarder(HTTPS経由でDatadogバックエンドに送信), DogStatsD(DatadogによるStatsDの実装で、デフォルトポート8125で実行されるメトリクスの収集及び集計デーモン)
  • 構成オプションや一般的な使用例を説明
hmatui66hmatui66

Chapter 3: The Datadog Dashboard

  • Dashbord の重要な機能: infra list, event, metric explorer, dashboards, integrations, monitors, advandec feature
  • event: datadog agent の再起動や新しいコンテナのデプロイなどのレベルのもの
  • 2種のDashboard: time board(時系列にメトリクスを並べる), screen board(時間の制約がない)
hmatui66hmatui66

Chapter 4: Account Management

  • ユーザー管理、ロールを使用したカスタムアクセス
  • organization: インフラの一部&その上のアプリの監視を分離できる
  • ベストプラクティス
    • 複数 organization で production 環境の監視をクリーンに
    • カスタムユーザーロールで最小限の権限をもたせる
    • SSO使う
    • programmatic access には service account を使う
hmatui66hmatui66

Chapter 5: Metrics, Events, and Tags

  • Datadogが大きく依存する2つの構成要素の「メトリクス」と「タグ」の定義方法について説明
  • Datadogが監視するインフラorアプリ内のアクティビティである「イベント」の説明と他のチャネルへの転送方法を説明
  • タグによるメトリクスやイベントのグループ化&検索方法を説明
hmatui66hmatui66

Chapter 6: Monitoring Infrastructure

  • 基本的なタイプの1つ、インフラ監視について説明
  • Datadog はホストレベル、コンテナレベルの両方を監視する機能を提供
  • Lambda などインフラ関係しないサーバーレスコンピューティングリソースも監視できる
hmatui66hmatui66

Chapter 7: Monitors and Alerts

  • Datadog モニターを作成 & メンテ(マニュアル、as code)する方法を説明
  • アラート通知をする方法
  • メンテナンス期間やシャットダウン期間中にダウンタイム機能を効果的に使用
hmatui66hmatui66

Section 2: Extending Datadog

  • すぐに利用できる標準監視機能があり、Agent をインストールすればすぐに利用できるが、包括的に監視するにはカスタムメトリクスで拡張する必要ある
  • 8-11章で拡張のためのインテグレーションを説明
hmatui66hmatui66

Chapter 8: Integrating with Platform Components

  • Platform Components についても一般的なものは標準で監視できるが、できないものはカスタムチェックオプションがある
  • Platform = クラウドサービスのことだけでなく、Proxy(NGINX, Apache, ...), 各種DBMS などミドルウェアも含む
  • スクリプトを /etc/datadog-agent/check.d にインストールすることでカスタムチェックを実装できる
hmatui66hmatui66

Chapter 9: Using the Datadog REST API

  • Datadog HTTP REST API を使ってDatadog と統合する方法を説明
  • API を使って、メトリクス or イベントを Datadog に publish するだけでなく、Datadog からデータを取得してレポートツールに読み込むなどもできる
  • 既存のインテグレーションが使える場合は、APIを使用した独自コード実装は避けるべき
hmatui66hmatui66

Chapter 10: Working with Monitoring Standards

  • 監視における標準実装である SNMP, JMX, StatsD を用いた拡張 option を説明
  • SNMP(ネットワークの監視), JMX(Javaアプリの監視), DogStatsD(任意のメトリクスの監視)
  • 利用は計画的に
    • SNMPでネットワークデバイスを監視するとメトリックが膨大になり、取捨選択ちゃんとする必要ある
    • JMXはアプリの動作を manipulate するためにも使えるが、監視インフラ側でそういうことはしないほうが良い
    • DogStatsDはサービスポートへのアクセス以外に認証を必要としないので実行環境のセキュリティを確保する必要ある
hmatui66hmatui66

Chapter 11: Integrating with Datadog

  • API や DogStatsD を使って Datadog を他のアプリと統合する方法を説明
  • クライアントは公式のものとコミュニティのものがある
  • 例として、一部のアプリデータをDatadogにpusblishしつつ、Zabbixと統合する方法を説明
hmatui66hmatui66

Chapter 12: Monitoring Containers

  • Docker や Kubernetes 上でログを収集する方法を説明
  • Live Container 機能で Kubernetes のリソース各種を見ることができる
  • コンテナから収集された情報を検索して見る方法を説明
hmatui66hmatui66

Chapter 13: Managing Logs Using Datadog

  • ログ集約とインデックス作成機能について説明
  • ログのフィルタリングや機密データのスクラビング(masking)方法を説明
  • ログのアーカイブや検索方法について説明
hmatui66hmatui66

Chapter 14: Miscellaneous Monitoring Topics

  • 最近利用可能になったモニタリング機能の AppDynamics, Security Information and Event Management(SIEM)、Catchpoint などについて説明
  • Synthetic monitoring を使うとロボットユーザーによるシミュレーションができる
  • Security rule の定義方法について説明
hmatui66hmatui66

Optimizing Java

https://www.oreilly.com/library/view/optimizing-java/9781492039259/

別のスクラップで書いていたがこちらで軽めにまとめる

hmatui66hmatui66

Chapter 1. Optimization and Performance Defined

  • この本はコードに適用するパフォーマンスのヒントのクックブックではなく、パフォーマンスエンジニアリングを生み出すためのさまざまな側面に焦点を当てる
  • JVMパフォーマンス・チューニングは実験科学であることを説明
  • 一般的なパフォーマンス指標と、パフォーマンスグラフの読み取り方について説明
hmatui66hmatui66

Chapter 2. Overview of the JVM

  • JVM が Java を実行する方法の概要を説明
  • HotSpot (JIT など)やメモリ管理(GC など)を説明
  • JVM の代表的な実装(Oracle, Zulu, Android, ...)やモニタリングツール(JMX, Java agents, JVMTI, The Serviceability Agentなど)について説明
hmatui66hmatui66

Chapter 3. Hardware and Operating Systems

  • Java アプリケーションを最適化するに当たって必要なハードウェアと OS の知識を説明
  • CPU関連: CPU キャッシュ, Translation Lookaside Buffer(TLB), 分岐予測 & 投機的実行, Hardware メモリモデル(Java Memory Model←12章で後述)
  • OS関連: スケジューラ, 時間の扱い, コンテキストスイッチ,

JVM ではシングルスレッドのアプリコードでも追加のプロセッサコアが利用できる、と書いてあったので後で調べる

hmatui66hmatui66

Chapter 4. Performance Testing Patterns and Antipatterns

  • パフォーマンステストのベストプラクティスとアンチパターンについて説明
  • パフォーマンスチューニングでどこに力を注ぐべきかを決める時の3つの黄金律
    • 気になるものを特定&測定する方法を見つける
    • 簡単に最適化できるものではなく、重要なものを最適化する
    • まずは big point をプレイする
  • アンチパターンのリストと、その多くが無意識の思い込みに基づいた認知バイアスによって起こることを説明
hmatui66hmatui66

Chapter 5. Microbenchmarking and Statistics

  • JVM の動的性質によりパフォーマンス数値を扱うのは難しく、特にマイクロベンチマークは難しい
    • 動的性質の理由例: JIT コンパイル、GC
  • マイクロベンチマークのデファクトツールの JMH を説明
  • JVM パフォーマンスの統計に関する内容を説明
hmatui66hmatui66

Chapter 6. Understanding Garbage Collection

  • Java GC を支える基本理論と、制御が難しい理由を説明
  • HotSpot のランタイムシステムの基本機能ついて紹介
  • HotSpot の最も単純なコレクターである並列コレクターを紹介
hmatui66hmatui66

Chapter 7. Advanced Garbage Collection

  • 適切なコレクタを決定する際のトレードオフについて概説
  • 基礎となる理論としてJVMセーフポイントとTri-Color Markingを説明
  • 上記これらのアイディアを実装する様々な最新のGCアルゴリズムを紹介
hmatui66hmatui66

Chapter 8. GC Logging, Monitoring, Tuning, and Tools

  • GCチューニング技術の概要を説明
  • 割当率の分析: GCを調整してパフォーマンスを向上させられるかどうかを判断するのに重要
  • Parallel GC, CMS, G1 に対する基本的なチューニング方法を説明
hmatui66hmatui66

Chapter 9. Code Execution on the JVM

  • JVM のバイトコードインタープリターの基本について説明
  • 実行可能コード生成の代替アプローチの AOT と JIT について説明
  • HotSpot JIT について説明
hmatui66hmatui66

Chapter 10. Understanding JIT Compilation

  • JIT コンパイルサブシステムの基本を説明
  • 最適化の一部を説明
  • 最適化の効果を JITWatch で観察する方法をあわせて説明
hmatui66hmatui66

詳解 Terraform 第3版 ―Infrastructure as Codeを実現する

https://learning.oreilly.com/library/view/xiang-jie-terraform-di-3ban/9784814400522/

hmatui66hmatui66

1章 なぜTerraformを使うのか

  • IaC ツールの整理。選択にあたったトレードオフを挙げて、各ツールの違いを解説
  • Dockerなどのサーバーテンプレートと組み合わせる場合、プロビジョニングツールである Terraform, CloudFormationなどがマッチ
hmatui66hmatui66

6章 シークレットを管理する

シークレット管理の第1ルールは次のとおりです。

シークレットをプレーンテキストで保存しない

シークレット管理の第2ルールは次のとおりです。

シークレットをプレーンテキストで保存しない

大事


先頭にスペースを入れたコマンドをヒストリファイルにシークレット情報を残さないようにする設定あるの、知らなかった。
https://qiita.com/P-man_Brown/items/56e76c516ab511635548

hmatui66hmatui66
hmatui66hmatui66

Intro

  • 3 つの柱
    • Big-picture thinking
      • 全体像を考える
      • 現在の時間を超えて考える
        • 例: 1年に渡るプロジェクトを開始、3年以内に会社が必要とするものを予測
    • Execution
      • プロジェクトはより乱雑で曖昧になる
      • 成功のためには、より多くの人が関与、より多くの政治資本、影響力、文化の変化が必要
    • Leveling up
      • 関係するエンジニアの基準とスキルをアップさせる責任が増す
      • 指導による意図的な影響だけでなく、role model としての偶発的な影響もある
  • ベースとなるのは tech knowledge and experience
    • だが技術的な知識では不十分
    • ヒューマンスキルが必要
      • コミュニケーションとリーダーシップ
      • 複雑さを乗り越える
      • 大局的に見る
      • 指導、しポンサー湿布
      • 他の人が関心を持てるように問題を組み立てる
      • リーダーであるかどうかにかかわらず、リーダとして行動
hmatui66hmatui66

Chapter 1. What Would You Say You Do Here?

タイトルは重要

ボトムアップで、すべてのアイディアが敬意をもって扱われる、という文化は素晴らしいが

「人々が自分たちが進歩していることを理解できるようにすること、自動的には権限を与えられない可能性のある人々に権限を与えること、そして期待されるコンピテンシー レベルを外部の世界に伝えることです。」

https://medium.com/s/engineering-growth-framework/engineering-growth-framework-overview-4e02ab330524

Why Do We Need Engineers Who Can See the Big Picture?

  • 単一チームのエンジニアはチームの目標を達成することに集中する可能性が高くなる
  • 多くの場合、1つのチームに属するように見える決定が、チームの境界を遥かに超えた影響を及ぼす
  • 現状を把握するのと同じくらい重要なのは、自分の決定が将来どのように展開されるかを予測できること
    • 1年後、何を後悔するか
    • 3年後、今から始めておけばよかったと思うことは何か
  • どのプラットフォームを標準化するかなどは微妙で物議を醸すことも多い
    • 決定のためにはコンテキストを共有し、他の人がそれを理解できるようにすることが不可欠

Why Do We Need Engineers Who Lead Projects That Cross Multiple Teams?

  • 現実のプロジェクトでは一部の責任は誰にも所有されず、その他の責任は2つのチームが負うことになる
  • 情報が流れなかったり、混乱して矛盾が生じる
  • チームは局所最適解を下すが、ソフトウェアプロジェクトは行き詰まる
  • →プロジェクトを進めるために必要なのは、全体に所有権を感じている人
  • なぜ TPM(technical program manager) ではだめ?
    • TPM はプロジェクトが納期通りに完了することを保証
    • スタッフエンジニアはプロジェクトが高いエンジニアリング基準に従って完了することを保証
  • TPM には求められず、スタッフエンジニアに求められること
    • 技術設計書を書く
    • テストやコードレビューのためのプロジェクト標準を設定
    • レガシーシステムの内部を深く調査してどのチームがレガシーシステムと統合する必要があるかを判断

Why Do We Need Engineers Who Are a Good Influence?

  • スタッフエンジニアはロールモデル
    • エンジニアリングの基準はプロジェクトで尊敬されているエンジニアの行動によって決まる
    • 例: 標準に何が書かれていてもシニアエンジニアがテストを作成していなければ、他のメンバーにテストを行うように説得できない
  • 経験のあるエンジニアは大局的、大規模プロジェクト、良い影響を与える仕事を行うべき
    • ただ、シニアエンジニアがコーディングと同時にそれらを実行することはできない
  • シニアエンジニアが1日中コードを書くとコードベースは良くなるが、彼らにしかできない他のことはできない
    • 技術的なリーダーシップは、職務内容の一部である必要あり

スタッフエンジニアの特性

  • マネージャーではなくリーダー
    • 直属の部下はいない、周囲のエンジニアの技術スキル向上に関与するが、パフォーマンスは管理しない
    • 教えることはリーダーシップの一形態
    • 静かに全員のレベルを引き上げる、技術的な方向性を決める、あなたが信頼しているという理由で、他の人々を納得させられる
  • 技術的な役割についている
    • エンジニアリングがどうあるべきかについて高い基準
    • コードや設計のレビューは同僚にとって有益
    • 意思決定時にトレードオフを理解し、他の人がそれを理解できるように支援
  • 自律性を目指す
    • マネージャーから伝えられる情報と同じくらい逆に彼らに伝える
    • 自分の時間を守り、構成するのは自分次第
    • 優先順位、納期、人との関係性を天秤にかけて、何をするかを判断
  • 技術的な方向性をきめる
  • 頻繁かつ上手にコミュニケーションをとる

役割を理解する

  • 組織のどこ(レポートチェーン)に位置するかを判断する必要がある
    • high
      • 広い視野、高度で影響力のある情報が得られる
      • low レイヤーと比べてマネージャーが使える時間ははるかに少ないので、サポートは少なくなる
    • low
      • 組織全体に影響を与えるのは難しい
      • マネージャーから学ぶことは少ない可能性
      • 上司の上司とスキップレベルの会議を行う必要があるかも