気軽に楽しくプログラムと遊ぶ

自分が興味があってためになるかもって思う情報を提供しています。

Mac Slack 便利なショートカット

移動系

説明 コマンド 補足
「未読」に移動する Command + Shift + A
「スレッド」に移動する Command + Shift + T
「DM」に移動する Command + Shift + K
「メンション&リアクション」に移動 Command + Shift + M

履歴

説明 コマンド 補足
履歴に戻る Command + [ or ← チャンネルごとの履歴
履歴に進む Command + ] or →

ワークスペース

説明 コマンド 補足
前のワークスペースに切り替え Command + Shift + [
次のワークスペースに切り替え Command + Shift + ]
特定のワークスペースに切り替え Command + 1~9

検索

説明 コマンド 補足
チャンネルやDMを検索する:Command + K
現在のチャンネルやDM内で検索する:Command + F チャンネルが決まっている場合
ワークスペース全体で検索する:Command + G とりあえず全体での場合

フォーカス移動

説明 コマンド 補足
メッセージエリアにフォーカスを当てる T

編集、書式設定

説明 コマンド 補足
Cmd + Shift + _ メッセージに絵文字リアクションを追加する
自分の直近のメッセージを編集 Cmd(Ctrl)+↑
ファイルをアップロードする Cmd(Ctrl)+U
全てのメッセージを既読にする Shift+Esc
文章を箇条書きにする command + shift + 8 選択した部分を箇条書きにする
文章をコードテキストにする command + shift + C 選択箇所の書式を変更
文章をコードブロックにする command + alt + shift + C

表示、非表示

説明 コマンド 補足
Cmd + Shift + D、Cmd + .  左右のサイドバーの表示非表示を切り替える

GitHub Actionsの書き方(基本)

GitHub Actionsとは?

ビルド、テスト、デプロイなどを自動化するCI/CDプラットフォームのこと。GitHub内のサービスのため、GitHub内で完結することができる。

GiHub Actionsの仕組み

  • 設置場所:.github/workflows
  • ファイル形式:yml
  • 記載内容:ワークフロー
  • トリガー条件:push, pull_requestなど

WorkflowはJob単位で分けられて、Runner(仮想マシンインスタンス)上で実行される。

JobはさらにStep単位に分けられていて、この中でコマンドが実行される。

GiHub Actionsの書き方

job(処理の最上位単位)

jobは複数定義可能で並列実行される

jobs:
  my_job1:
    name: My job1
  my_job2
    name: My job2

on(処理実行条件を指定)

on: [push] # push時にjobsを実行
イベント 説明
push リモートリポジトリへpush時
pull_request プルリクエスト作成時
deployment デプロイ時
release リリース時
issues GitHub Issues関連の処理発生時
schedule cronによる定期実行

上記以外のイベントはこちらを参照

run-on(ジョブを実行するOS(ランナー)を指定)

runs-on: ubuntu-latest # ubuntuの最新版を指定

uses(第三者もしくはGitHubが作成したActionsを利用)

- name: Checkout
    uses: actions/checkout@v4

usesに指定できるActionsは以下で検索して調べる
GitHub Marketplace · Actions to improve your workflow · GitHub

@以下に指定するバージョンの扱いについては以下が詳しかった
GitHub Actions の uses でメジャーバージョンを参照するのはリスク マイナーバージョン指定が良さそう。信頼性が懸念される場合は、SHA指定が一番安全

Actionsの信頼性は、GitHub Marketplace の「Verified creator」バッジが参考になる

step, run(job内のstep要素とコマンド実行するrun)

リモートリポジトリにpushするとファイル構成の確認、actions/checkout@v4を実行する

name: command
on: [push]
jobs:
  command:
    name: Use Linux commands
    runs-on: ubuntu-20.04
    steps:
      - name: Inspect files before checkout
        run: ls -la # Linuxコマンドを実行可能
      - name: Checkout
        uses: actions/checkout@v4 # ワークフローを実行するリポジトリをチェックアウト

env(ワークフロー内に環境変数を設定)

変数名: 設定値という書き方で設定可能

env:
  SECRET_KEY: test
  ALLOWED_HOSTS: 127.0.0.1

参考URL

Apache Kafkaとは?

Apache Kafkaとは?

複数台のサーバーで大量データを処理する分散メッセージングシステムのこと。

メッセージングシステム

リアルタイムに生成される大量データを中継するシステムのこと。

データ生成場所とデータ利用場所が複数ある場合、そのデータを直接やり取りすると複雑になっていくため、一時的にデータを貯めて置く場所としてこのシステムは使われる。

利用メリット

  • データ生成場所・データ利用場所ともに接続先を一つにできるため、シンプルな構成にできる。
  • 新しい データ生成場所・データ利用場所が作られてもメッセージングシステムに繋げば良いだけなので実装コストを下げられる。

Apache Kafkaの構成

構成要素 説明
Broker データを送受信するサービスで中継役
Message Kafkaが受診し送信するデータの単位
Producer データの送信元。BrokerにMessageを送信する
Consumer データの送信先。BrokerからMessageを取得する
Topic Mesageを種類ごとに管理するためのストレージ。Broker上で管理

Apache Kafkaの特徴

分散システム

データ量が増えてくると障害時にデータ欠損やデータ送信失敗となったりする。これらに対応するために分散システムを実現している。

構成要素 説明
Partition Topicを細分化する単位
Replica(Leader) Partitionの複製。Producerからメッセージを受信、Consumerに送信する。各Partitionに必ず一つ存在
Replica(Follower) Partitionの複製。Leader Replicaからメッセージを取得して複製。障害時に送信する
  • 各Replicaは異なるBrokerに配置されることで分散処理を実現
  • 一つのMessageの複製が複数サーバーで管理される

分散システムのメリット

  • スケールアウト可能:Brokerを増やしPrtitionを再配置することで役割の分散と性能向上を実現できる
  • データ欠損の低減:別Brockerにデータの複製があるため、障害が発生してもデータがなくならない。Leaderで障害が発生してもFollowerがLeaderの役割を引き継ぐためデータ送受信を継続できる

データの永続化

KafkaではBrokerがProducerからMessageを受け取ると、ディスク上へ保存する。これによりConsumerは任意のタイミングでMessageを取り出し可能になります。

データ永続化によるメリット

  • バッチ化の実現
    • Brocker上に溜まった複数MessageをConsumerが一括受信する。データを順次処理するストリーム処理なども実装かのう
  • Consumber障害発生時のBrokerへの影響が少ない
    • Consumerが障害となってもBroker側でデータ送信停止などがいらない。Consumerからのリクエストに応じてBrockerが送信する仕組みになっているので

参考URL

Intellij 便利プラグイン

便利そうと思って導入したプラグインの概要について以下に記載する。
詳しい内容は、参考URLを参照のこと。

便利プラグイン

コード共有

  • GitLink:エディタ上のコードを右クリックで、コード共有リンクコピーのメニューを出せる

コード理解

  • Find Pull Request:エディタ上のコードを右クリックで、カーソルのコードを最後に編集したPRへジャンプするリンクを表示
  • GitToolBox:選択行右側にCommitのAuthor名やCommitメッセージが表示

コードリーディング支援

  • Rainbow Brackets:対応括弧をレインボーにハイライト
  • JsonParser:JSONのvalidateやformatを行ってくれるものです。 手入力したJSONが正しいフォーマットになっているか確認したい、一行にまとめられていて人間が理解するのが困難なJSONを読みたいに使える

操作効率化

  • Key Promoter X:マウスのクリックで行った操作に対して、ショートカットを使わなかったことの指摘を通知

参考URL

Confluence PlantUML シーケンス図 ノートの表示位置調整

メッセージに付けるノートが思うように出力できなかったので、記載しておく

  • note 【表示位置】 of 【起点の要素】
  • 【表示位置】 :right left over
  • 【起点の要素】:participantで定義した要素

参考ソースと画面イメージ

@startuml
participant Alice
participant Bob
note left of Alice #aqua
This is displayed
left of Alice.
end note

note right of Alice: This is displayed right of Alice.

note over Alice: This is displayed over Alice.

note over Alice, Bob #FFAAAA: This is displayed\n over Bob and Alice.

note over Bob, Alice
This is yet another
example of
a long note.
end note
@enduml

参考

plantuml.com

AWSやKubernetes周りのツール 概要

AWS App Runner

  • ECRにコンテナイメージをpushまたは、GitHubにコードpushすると、自動デプロイしてくれる
  • コンテナがデプロイされるとApp RunnerがマネージドのLBを設定してくれる
  • コンテナ管理とかVPC周り、ALB,NLBとかscalingなどを隠蔽して提供してくれる

Kubernetes Ingressコントローラー

参考

サービスメッシュとIstio

マイクロサービスの課題

  • 近年、マイクロサービスが大流行しているがネットワークに関係する課題がある
    • トラッフィク管理、可観測性、セキュリティの3つ

ネットワークに由来する課題解決のための機能

マイクロサービスシステムの運用には、分散システムのネットワークに由来する課題が存在しており、その解決のための様々な機能の実装が必要となる。

  • トラフィック管理
    • サービスディスカバリ
      • サービスを利用する際、ドメイン名などのサービス識別子からIPアドレスなどの実サーバ接続情報を明示的/暗示的に得ること
    • 負荷分散
    • ロットリング
      • 一定の時間内に、事業者が特定の操作に対して送信できるリクエストの数を制限するプロセス
    • サーキットブレイカ
  • 可観測性
    • モニタリング
    • ロギング
    • 分散トレーシング
  • セキュリティ
    • サービス間の認可
    • 相互TLS

各種ライブラリを用いて、これらを実装して問題解決することも可能であるが、多くのマイクロサービスを抱える場合、統一的な問題解決をするのが難しくなってくる。

サービスメッシュが解決する課題

すべてのマイクロサービス間の通信に対して、一貫した仕組み(サーキットブレーカー、ログ、メトリクス、認証認可など)を提供するのがサービスメッシュ。

Istioの概要

Data Plane

  • マイクロサービス間のすべてのネットワーク通信を仲介・制御する
  • すべてのPodにEnvoyをサイドカープロキシとして配備する
  • アプリケーションは、IstioやEnvoy Proxyのための設定が不要となり、ビジネスロジックの実装に集中できるようになる
  • マイクロサービス間の通信の観測結果を収集し、レポートする

Control Plane

  • Data Planeを管理する
  • istio-initによって、Kubernetesクラスター内のすべてにEnvoy Proxyを注入する
  • RouteRuleなどの設定を常に最新に保つように、Reconciliation Loopを実行する
  • 可観測性の向上のためにログ集約するなどを行う

Istiod

  • サービス検出・構成・証明書管理を行う
  • 構成要素
    • Mixer : Envoy を通して各サービスのデータを収集し、その情報を元にアクセスコントロールを行う
    • Pilot : サービスディスカバリやトラフィック管理などを行う
      • A/Bテスト・カナリーリリースの実現や、タイムアウト・リトライ・サーキットブレーカーなどの手法を用いて Fault Isolation(障害の分離)の問題を解決することができる
    • Citadal : サービス間認証とエンドユーザ認証を実現する
      • この認証を利用することで、ポリシーベースでサービスメッシュを管理することができる。

サービスメッシュの本質

  • サービスメッシュの解決課題は、トラフィック管理、可観測性、セキュリティではない
  • インフラのコード化を実現したのがKubernetesこれをネットワークの世界に適用したのがサービスメッシュツールであるIstio

サービスメッシュの仕組み

  • サービスメッシュはアプリのサイドカーなので、拡張が可能
  • IstioのProxyとしてのEnvoyは、Envoyフィルタを利用して拡張を行う
  • Envoyフィルタは、Envoyコア機能に影響を与えずにカスタム機能を定義する
  • envoy.yamlによって追加機能をコード化することでIaCを実現可能

参考