harukin721

主に学習記録

「CloudNative Days Tokyo 2023」に参加した。

12/11-12 の 2日間「CloudNative Days Tokyo 2023」に参加させてもらった。

event.cloudnativedays.jp

初めてテックカンファレンスに参加して、普段の業務と関連のあるもの中心にいろんなセッションを聴くことができて楽しかったです！

セッション

2日間ともこれまでの業務と関連のあるセッションを選択したからということもあると思うけど、自分が思っていたよりもセッション内容を理解できることが多かった気がする。

note さんの EKS や PayPay さんのプライベートクラウドなど、他社のパブリッククラウドとプライベートクラウドのセッションを聴くことができてよかった。その他にも K8s のトラブルシューティングや K8s クラスタを引き継ぎ、 GitOps, ArgoCD など、いろんなセッションを聴くことができて勉強になった。

爆速でアーカイブ動画をあげていただいているので、現地で聴けなかったセッションの動画も見てみようと思う。

あとは、ペパボに入社してから Kubernetes であったり VM であったり、その他にもたくさんの技術に触れる機会が与えてもらっているおかげで知識の幅が着実に広がっていると実感することもできた。まだまだわかった気になっていることも多々あると思うので、基本的なことを正しく理解することをちゃんと意識してこれからもやっていきたい。

おわりに

1日目の懇親会で、前職のスタートアップで AWS を触っていたときにお世話になっていた本の著者の方とお話しすることもできた。来年3月頃に池袋で AWS のイベントがあるようなので、ぜひ参加したいと思っている。

あと、某SI の新卒の方とお話していて東京の同期だけで 600人いると聞いて圧倒された。

2日間も参加させていただいてありがとうございました。楽しかったです！

同い年ぐらいの方もいっぱいすごい... ってなっていた。強くなりたい...！

マスタリングTCP/IP 入門編 の「第6章 TCPとUDP」を読んだ

マスタリングTCP/IP 入門編 の「第6章 TCPとUDP」を読んだ。ソケットプログラミングを理解したい。

トランスポート層

OSI 参照モデルの真ん中に位置していて、第3層以下が提供するサービスを第5層以上に提供するときの仲立ちをする。IP に信頼性がないが TCP は信頼性を提供する。これにより、第5層以上は安心して下位層に通信処理を任せられる。

ソケット

アプリケーションから TCP や UDP を利用して通信するときには、ソケットという API 
が広く使われている。アプリケーションはソケットを利用して、通信相手の IPアドレスやポート番号の設定、データの送信や受信の要求を行う。そうすることで OS が TCP/IP による通信を行ってくれる。
ソケットは OS が持っている TCP/IP の機能を提供することが目的で、第5層以上の固有の機能は提供しないので TCP や UDP を直接使うことを意識しながらプログラムを作成する必要がある。( まだよくわかっていない )

※ この負担を軽減して、アプリケーションプログラムを作成できるようにライブラリやミドルウェアが提供されているが、結局これらのライブラリやミドルウェアはソケットを使って作られている。

TCP と UDP

必要となる通信の特性により、使用するトランスポートプロトコルを選択する

  • TCP (Transmission Control Protocol ）
    • コネクション型で、信頼性のあるストリーム型(切れ目のないデータ構造)のプロトコル
    • 「伝送、送信、通信」を制御して信頼性のある通信を提供する
    • コネクション制御があるので、通信相手が存在する時にだけデータを送信することができるので無駄な通信を抑制できる
    • ネットワークが混雑してふくそう状態にならないように、パケットの送信量を調整してくれる
    • 使用用途 :
      • データの喪失があっては困る通信
      • ファイル転送などのインターネットを介して大量のデータの転送 ...etc
  • UDP ( User Datagram Protocol ）
    • コネクションレス型で信頼性のないデータグラム型のプロトコル
    • 複雑な制御は提供せず IP を用いたコネクションレスの通信
    • 細かな処理はアプリケーションプログラム側に制御を任せる
    • いわば UDP は「アプリケーションを作ったユーザーの言うがままになる」
    • 使用用途 :
      • 総パケット数が少ない通信である DNS や SNMP
      • 即時性が必要な通信である動画や音声などのマルチメディア ...etc

やっていく

社内Slackでみんないろいろ教えてくれる。

参考

www.ohmsha.co.jp

ryuichi1208.hateblo.jp

rnakamine.hatenablog.com

宿題

  • C や Go で実際にソケットプログラミングを試す
  • Connection refused になったらどうやって問題を切り分けますか
  • サーバでどんなソケットが作成されているか、どのポートで listen されているかを調べるコマンドを理解する

ざっと ArgoCD を勉強した

ArgoCD を雰囲気で触ってしまっているので... 。

まず GitOps とは Git 上でマニフェストを管理し、マニフェストリポジトリの内容を常にクラスタに同期するデプロイメントの手法のこと。kubectl コマンドで変更の操作を行うのではなく、Git によってすべての操作や管理をおこなってくれる。

ArgoCD

GitOps を提供するツールの 1つとして ArgoCD がある。ArgoCD はデプロイメントに特化していて CI の機能はない。Argo CD は Web UI があるのが特徴的で、アプリケーションの状態をリアルタイムに可視化してくれている。

現状の Kubernetes クラスタの状態と Git のマニフェストリポジトリの状態を可視化、差分があればアプリケーションを同期する。Argo CD のカスタムリソースは主に 2つある。

Application の状態

  • SYNC STATUS : Git リポジトリのマニフェストの内容とデプロイされた各オブジェクトの同期する関する状態
  • HEALTH STATUS : Kubernetes に登録された各オブジェクトの稼働に関する状態
    • Healthy : オブジェクトが正常に稼働している状態
    • Progressing : まだオブジェクトが稼働していないが、稼働状態へ更新途中の状態
    • Degraded : 同期を試みたが、タイムアウトしてしまい Healthy 状態にできなかった状態
    • Missing : Git リポジトリにマニフェストがあるが Kubernetes クラスタ上にオブジェクトがデプロイされていない状態

マニフェストの同期

Git リポジトリの変更に合わせて自動同期する。Argo CD には様々な同期ポリシーが用意されている。同期設定方法によって、運用しているアプリケーションやリリースの動作に大きく影響を及ぼすので理解を深めておくこことが重要。

自動同期ポリシーは、マニフェストリポジトリの状態と Kubernetes クラスタ上に展開されたオブジェクトが異なる場合に状態を動的に調整する機能。

  1. destination : デプロイメント先の Kubernetes クラスタと名前空間を指定
  2. project : Application が属する AppProject を指定
  3. source : デプロイメント元のマニフェストリポジトリと対象を指定
  4. syncPolicy : 自動同期ポリシーを指定

syncPolicy(automated) のみ見ていく。

このフィールドに「automated」を指定すると、マニフェストリポジトリへの自動同期が有効化される。

automated フィールド

  • prune : マニフェストリポジトリにあるマニフェストが削除された際に、稼働中のリソースを削除するか否か。デフォルトは false 。
  • allowEmpty : prune が設定されている場合に、リソースが空の状態を許可するか否か。デフォルトは false 。
  • selfHeal : リソースの状態がマニフェストと異なる場合に、動的にマニフェストの状態を維持し続ける(Argo Application Controller の自動回復検知時間であるデフォルト5秒間隔)。デフォルトは false (同期は1度、同じハッシュ値)。
syncPolicy:
  automated:
    prune: true
    selfHeal: true
# 無効
syncPolicy:
  automated: {}

Argo CD Web UI からも同じようなことができる。また Argo Rollouts は別の機会で。

参考

argo-cd.readthedocs.io

circleci.com

book.impress.co.jp

hiroki-hasegawa.hatenablog.jp

ありがとうございました。

 

【再学習】Ruby on Rails の Active Record

Ruby on Rails の Active Record を再学習した。チーム内の LTで話した。 

railsguides.jp

Active Record

MVC の モデルに相当し、ビジネスデータとビジネスロジックを表す。データベースに恒久的に保存される必要のあるビジネスオブジェクトの作成と利用を円滑に行なえるようにする。モデルとデータベースのテーブルは 1 対 1 の関係にある。データの操作を簡素化してくれている。

モデルクラスを作成して、それにデータベースのテーブルのカラムを属性として追加して、モデルのインスタンスがを通じてデータベースのレコードにアクセスするイメージ。

-> Book モデルが books テーブルにマッピングする。

ORM (オブジェクト/リレーショナルマッピング) なので SQL を直接書かなくてもよい。SQL を抽象化してくれているので MySQL であることを特に意識する必要がない。PostgreSQL であってもとくに SQL の変更は必要ない。

( 勉強には sqlite を使うとよい。)

ORM (オブジェクト/リレーショナルマッピング) 

  • モデルおよびモデル内のデータを表現
  • 関連付けられているモデル間の継承階層を表現
  • モデル同士のアソシエーション
    • テーブル間の関係を表現し、それに基づいてデータを取得・保存
  • データをデータベースで永続化する前のバリデーション
    • 特定の条件を満たすかの確認
  • データベースをオブジェクト指向スタイルで操作 ...etc

MySQL 5.7 から 8.0 へのアップデート

dev.mysql.com

  • 認証プラグインのデフォルトが mysql_native_password から caching_sha2_password が使用されるようになっている
  • 予約語が変更されていないかの確認
    • なにか変更があるとどこかで見た記憶
  • ストアドプロシージャ(データベース内に保存され、再利用可能な一連のSQL ステートメントを含むプログラム)、関数の作成や呼び出しなどに関するものが変更されていないかの確認 ...etc

なにを意識してコードを理解すればよいか

  • モデルのクラス構造と継承関係:

    • モデルは通常 ApplicationRecord クラスを継承

    • モデルクラス内で定義された属性やメソッドを確認

  • マイグレーションファイル:

    • データベースのテーブル構造はマイグレーションで管理

    • モデルの属性とデータベースのカラムの対応関係を確認

  • クエリメソッドの使用:

    • モデル内でのデータベースクエリの使用方法の確認

    • where、order、findなどのメソッドを使用してデータを取得手法

  • 関連付け:

    • モデル間の関連付けの確認

    • belongs_to や has_many などのメソッド

    • データの関係性を把握することもやっておきたい

  • スコープとコールバック:

    • モデルに定義されたスコープやコールバックを確認

    • データベース操作においてどの条件や処理が適用されているか

などを、おおよそ理解しながら進める。

Nginx のレートリミットの値に標準偏差を活用

Nginx のレートリミットを設定する際に、標準偏差を活用した。

標準偏差とは、データが平均値からどれぐらい散らばっているかを示す指標のこと。

𝜇±𝜎の区間に入る確率は約68%
𝜇±2.0𝜎の区間に入る確率は約95%
𝜇±2.5𝜎の区間に入る確率は約98.76%
𝜇±3.0𝜎の区間に入る確率は約99.7%

gmo-research.jp

www.kagakusense.com

Nginx のレートリミットの値を決める

BigQuery に蓄積されている直近3ヶ月の Nginx のアクセスログを活用して IP単位のレートリミットの値を決定した。

  1. 直近 3ヶ月の remote_addr ごとの秒ごとのリクエスト数を集計する
  2. 全 remote_addr と秒別の平均リクエスト数と標準偏差を計算する
  3. 平均から 𝜇±2.5𝜎 以上離れた秒単位のレコードに含まれるリクエスト数を特定する
  4. 平均から 𝜇±3.0𝜎 以上離れた秒単位のレコードに含まれるリクエスト数を特定する

3 で算出した数値「80」は正常なリクエストとして扱い、4 で算出した数値「95」は異常なリクエスト( 一時的な外れ値として許容 )として扱う。 95 から 80 を引いた値「15」を burst の値( nodelay あり )とした。

@pyama86 さんに、このように実例を踏まえてロジカルに決めていく方法を教えていただきました。ありがとうございました。

以下の本をおすすめしてもらったので読んでいる。

str.toyokeizai.net

Nginx の参考

Nginx の「burst なし」「burst あり、nodelay なし」「burst あり、nodelay あり」は以下のブログで勉強させていただきました。ありがとうございました。

miraitranslate-tech.hatenablog.jp