「Training Site Reliability Engineers: What Your Organization Needs to Create a Learning Program」を読んでみた
はじめに
先日のSRE Gapsを視聴して、Googleが無料で公開しているSREに関するドキュメントがあることを知った。その中で「Training Site Reliability Engineers: What Your Organization Needs to Create a Learning Program」というドキュメントがあったので、読んだ。本ドキュメントで気になった部分だけ、感想を書いてます。
より詳細を見たい方は、以下参照してください。
Training Site Reliability Engineers: What Your Organization Needs to Create a Learning Programとは
GoogleのSRE教育チームがどのようにSREを教育していった方がいいのかを事細かに説明している。例えば、
などが説明されている。
SREトレーニング技術
以下、大まかに5つのレベルで説明されている。日本語訳は、主観的でイメージがわきやすいように翻訳してます。
- Sink or Swim: 一か八か
- Self-Study: 自己学習
- Buddy System: ペアプロやペアトラブルシューティング
- Ad Hoc Classes: 別チームとのディスカッション
- Systematic Training Program: 組織的なトレーニングプログラム
トレーニングをする労力が上に位置するほど低くなり、下に位置するほど高くなる。
Sink or Swim: 一か八か
これはチームに新しく入ってきたメンバー自身に対して、資料やトレーニングプログラムを持たずに物事を学んでもらう方法が当てはまると思う。最も労力が少ないが、ストレスがたまり、自信がつかない方法(Imposter syndrome)でもある。日本の企業だと、現場に入れた後、放置プレイで仕事してもらう方法に当てはまることができる(通称、OJT)。
Self-Study: 自己学習
メンバーに学んでもらいたい項目をチェックリストでまとめて、提供する方法。各項目の学習媒体としては、ドキュメント、ビデオ、技術演習などである。しかし、技術が古くなり、内容のメンテナンスする必要が出てくる。またメンテナンスを怠ると、メンバーに対して学習時間の無駄な浪費につながる。
Buddy System: ペアプロやペアトラブルシューティング
オンコールなどの実務に対して、経験者とメンバーでペアを組んで取り組む方法である。この際に、Self-Studyで使われた学習媒体とつけ合わせてすることで、より効率的な学習方法になると言われている。
Ad Hoc Classes: チーム単位によるディスカッション
指導者と小さなチームが参加したディスカッション方法である。この際に、ホワイトボードを使い、システム図などを描写しながら、ディスカッションをすることで、より効果的な学習に繋がる。新しいメンバーに既存のメンバーでさえ知らない最新の技術やトピックを学んでもらうことにより、全体的なチームの底上げにも繋がる。
Systematic Training Program: 組織的なトレーニングプログラム
モニタリング、インシデント対応、ポストモーテムの作成などの実務により近い形で学ぶトレーニング方法であり、最も労力がかかる。
所感
新メンバーにどうやって学んでもらうか悩んでいたことがあったが、個人としてBuddy Systemまで対応できると思えた。Ad Hoc ClassesやSystematic Training Programにおいて、組織的に動く必要があるので、マネージャークラスが考慮することだと思えた。しかし、トレーニングもエンジニアリングの必要不可欠な要素なので、今後のキャリアのために、頭の隅に入れておくと役に立つのかもしれない。
AWS DBサービス集
ざっくりとした概要
| サービス名 | 概要 |
|---|---|
| RDS | AWSが提供するマネージド型のリレーショナルデータベースのサービス。エンジンのタイプとして、MySQL/SQL serer/Amazon Auroraなどが提供されている。 |
| Amazon Aurora | AWSが提供する分散型のリレーショナルデータベースのサービス。分散高速処理を持つNoSQLと容易のデータ操作性を持つRDBの両方の特徴を持っている。またMySQLとPostgreSQLとの互換性も持っている。 |
| DynamoDB | AWSが提供するマネージド型のNoSQLデータベースのサービス。キーバリューで、結果整合性モデルを採用されている。ユーザー行動/セッション情報などのデータやログ管理に向いている。 |
| Kinesis | AWSが提供するIoTやSNSなどのビックデータに対するストリームデータ処理用のサービス。ストリーミンデータ処理として、Apach Kafkaと同様な立ち位置である。 |
| Redshift | AWSが提供するデータウェアハウス(DWH)向けの分散・高速処理を可能としたリレーショナルデータベースのサービス。データの抽出や集約に特化したBIデータ分析用の用途として用いられる。 |
| ElastiCache | AWSが提供する高速なRead/Writeが可能なインメモリキャッシュ型DBのサービス。種類として、RedisとMemcachedが提供されている。 |
RedisとMemcahcedの違い
| Redis | Memcached |
|---|---|
| スナップショット機能がある | スナップショット機能がない |
| 永続化可能 | 永続化不可能 |
| フェイルオーバーや復元可能 | フェイルオーバーや復元不可能 |
勉強用 AWS VPCリソースのメモ
AWS VPCリソース
| VPC リソース名 | 区分 | 概要 |
|---|---|---|
| サブネット | VPC | AWSの仮想ネットワークに対して、論理的にネットワークを分離することができるリソース。インターネットゲートウェイに対して接続されているサブネットをパブリックサブネットワークと呼び、それに接続されていないサブネットをプライベートサブネットワークと呼ぶ。 |
| ルートテーブル | VPC | サブネットまたはゲートウェイからのネットワークトラフィックの経路を決定する(ルーティング)。一般的なロードバランサーのルーティングテーブルにイメージが近いと思われる。 |
| インターネットゲートウェイ | VPC | インターネットから流れてきたトラフィックをAWSのサービスにルーティングするリソース。 |
| Egress Only インターネットゲートウェイ | VPC | 上記のインターネットゲートウェイに対して、IPv6に対応したリソース。 |
| キャリアゲートウェイ | VPC | 5G用のWavelengthゾーンに対して接続するゲートウェイのリソース。 |
| DHCPオプションセット | VPC | VPC内のインスタンスに対して、DNS/NTPなどのサービスを提供するリソース。デフォルトでは、ip-**-**-**-**のようなホスト名を提供している。 |
| Elastic IP | VPC | インターネットからアクセス可能なパブプリックIPv4を提供するリソース。 |
| マネージドプレフィックスリスト | VPC | 特定のサブネットのCIDRをセットできるリソース。 |
| エンドポイント | VPC | AWSの他リージョンのVPCと接続できるリソース。 |
| NATゲートウェイ | VPC | プライベートIPとパブリックIPを変換するリソース。返信用トラフィックのために使用される。 |
| ピアリング接続 | VPC | プライベートサブネットワークに属するインスタンス同士を1対1でプライベートなトラフィックの通信を行うことができるリソース。DR(Disaster Ricovery)構成などを行いたい時に使用する。 |
| ネットワークACL | セキュリティ | VPC/サブネットに対して、インバウンドとアウトバウンドのトラフィックに対して通信制御するファイアウォールのリソース。 |
| セキュリティグループ | セキュリティ | EC2インスタンスが属するVPCの仮想的なファイアウォール。インバウンド(Ingress)とアウトバウンド(Egress)へのリク |
| Transit Gateway | Transit Gateway | 。複数の他VPCに接続するリソース。ピアリング接続は1対1での静的な接続になるが、Transit Gatewayでは動的に複数の他VPCにトラフィックの通信を可能にする。 |
外部からcurlを用いてk8sリソースにアクセスする
はじめに
外部からKuberernetes(以下、k8s)のリソースにアクセスしたいことがあったりします。特にcurlを用いたリクエストの送信やgo/pythonなどを使った自動化など。今回はcurlを使ったリクエストの送信方法をまとめています。
実装
必要となるk8sリソース
k8sリソースを外部からリクエストを送る場合、以下のリソースを設定する必要があります。
service accountsecretclusterroleclusterrolebinding
以下、上記のk8sリソースの関係図になります。
service accountとsecretの作成
最初に、system userのようにPodなどに任意の処理させる用のアカウントとしてservice accountを作成します。またservice accountを作成した場合、secretは自動的に作成されます。
# service accountのyamlを作成 $ kubectl create sa test-sa --dry-run=client -o yaml > test-sa.yaml $ cat test-sa.yaml apiVersion: v1 kind: ServiceAccount metadata: creationTimestamp: null name: test-sa # test-saを作成 $ kubectl apply -f test-sa.yaml serviceaccount/test-sa created # test-saを確認 $ kubectl get sa NAME SECRETS AGE default 1 1d test-sa 1 23s # test-saのsecretを確認 $ kubectl get secret NAME TYPE DATA AGE default-token-nm8bq kubernetes.io/service-account-token 3 1d test-sa-token-jrmqf kubernetes.io/service-account-token 3 58s
clusterroleの作成
デフォルトで作成されているclusterroleのadminを使用するので、任意のclusterroleは作成しません。
clusterrolebindingの作成
先ほど作成したservice accontとclusterroleを紐づけるために、clusterrolebindingを作成します。
# clusterrolebindingのyamlを作成 $ kubectl create clusterrolebinding test-clusterrolebindng --clusterrole=test-clusterrole --dry-run=client --serviceaccount=default:test-sa -o yaml > test-clusterrolebindng.yaml $ cat test-clusterrolebindng.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: creationTimestamp: null name: test-clusterrolebindng roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin subjects: - kind: ServiceAccount name: test-sa namespace: default # test-clusterrolebindngを作成 $ kubectl apply -f test-clusterrolebindng.yaml clusterrolebinding.rbac.authorization.k8s.io/test-clusterrolebindng created # test-clusterrolebindngを確認 $ kubectl get clusterrolebinding test-clusterrolebindng NAME AGE test-clusterrolebindng 53s
外部からcurlのリクエストを送信
外部からcurlを用いて、httpsリクエストを送信できるk8sリソースの準備ができました。リクエストを送信するのには、service accountのsecretにあるTOKENが必要になります。以下のように環境変数を定義してからリクエストを送信します。
$export TOKEN=`(kubectl get secret test-sa-token-jrmqf -o json | jq -r .data.token | base64 -d)`
$ curl -g -H "Content-Type:application/json" --header "Authorization: Bearer $TOKEN" --insecure "https://$apiserver_ip:$apiserver_port/api/v1/namespaces/default/configmaps"
{
"kind": "ConfigMapList",
"apiVersion": "v1",
"metadata": {
"selfLink": "/api/v1/namespaces/default/configmaps",
"resourceVersion": "35090648"
},
"items": []
}
これでk8sから、レスポンスが返ってきたことがわかります。
所感
本記事で扱ったk8sリソースの理解不足があったりしたので、まとめてみました。意外と勉強になったなと思います。
勉強用 AWSサービスのメモ
大枠なAWSサービス
| サービス名 | 概要 |
|---|---|
| EC2 (Elastic Compute Cloud) | AWSの最も基本的なサービス。OS/Memory/CPU/Storageなどの設定が可能。イメージ的にはVirtual Machine(VM)やOpenStackのCompute Nodeに近い。EKSを用いた場合はContainerのInstanceになると思われる。 |
| EKS (Elastic Kubernetes Service) | AWSが提供するKubernetesのアプリケーションを実行するサービス。役割としては、KubernetesのMaster Nodesを担っている。AWS公式では、Controle Planeとも呼ばれている。 |
| S3 (Simple Could Service) | AWSが提供するオンラインストレージ。EC2に直接アタッチすることはできない。 |
| CloudFormation | AWSが提供するAWS自身が提供するサービスに対して、Infrastructure as Code(IaC)によってモデリングするサービス。 |
| ACM (AWS Certificate Manager) | AWSが提供する証明書(SSL/TLS)を管理するサービス。AWSで作ったWebサービス等に、HTTPS通信を使いたい場合などに使う。 |
| EBS (Elastic Block Store) | AWSが提供するブロックストレージサービス。EC2から直接アタッチすることが可能。EKSにおいて、PV(Persistent Volume)として使用する。 |
| CodePipeline | AWSが提供する継続的デリバリー(Continuous Delivery: CD)。アプリケーションの構築、テスト、デプロイを自動化する。またGitHubやサードバーティのサービスとのプラグインがある。 |
| Fargate | AWSが提供するEKSのData Plane。いわゆる、KubernetesにおけるWorker Nodeにあたる。EC2とは違って、DataPlaneであるVMのシステム運用管理が不要となる。しかし、VMへのアクセスができないため、DataPlaneの拡張性が乏しいことやモニタリングへの制限があると思われる。 |
| IAM (Identity and Access Management) | AWSが提供するユーザーの認証・認可するサービス。 |
| CloudWatch | AWSが提供する各サービスを可視化するモニタリングシステム。またlogの収集・保存やアラートの送信も可能。 |
| CloudFront | AWSが提供するCDN (Contents Delivery Network)サービス。Javascriptのみで開発可能。 |
| Lambda | AWSが提供するサーバレスな環境でプログラムが実行できるサービス。特定の言語で開発可能。 |
| CloudTrail | AWSアカウントによる操作やAPIのログを保存するサービス。一定の通信量まではの料金は無料。 |
| DirectConnect | オンプレ環境から物理的にAWS環境に接続する専用線サービス。 |
| Route 53 | AWSが提供するDNSサービス。 |
CDN: Webサービス配信の大元となるオリジンサーバーの負荷を軽減するために、ユーザーの近くにキャッシュサーバー(エッジサーバー)を配置したネットワーク構成。これにより、従来のオリジンサーバーの負荷が軽減され、ユーザーへの応答処理を向上させる。
「Kubernetes on AWS 勉強用」CloudFormationでROLLBACK_COMPLETEになる
はじめに
Kubernetes on AWSを勉強していて、第２章のCloudFormationの設定登録においてテンプレートをアップロード後、ROLLBACK_COMPLETEになったので、メモ。
Kubernetes on AWS ~アプリケーションエンジニア 本番環境へ備える | 会澤 康二, 佐藤 和彦 |本 | 通販 | Amazon
CloudFormationとは
AWS CloudFormation は Amazon Web Services リソースのモデル化およびセットアップに役立つサービス(以下、引用)になります。あらゆるAWSのリソースをIaC(Infrastructure as Code)として定義し、リソースの構築や管理の工程を簡単にできるものだと思われる。
エラー事象
CloudFormationに01_base_resources_cfn.yamlをアップロードして、設定を登録します。そうすると、以下のようにROLLBACK_COMPLETEになり、次へのステップが進めません。サンプルがあるyamlは以下、GitHubにあります。
https://github.com/kazusato/k8sbook
eks_test > EventsのStatus Reasonを見ると、どうやらサンプルyamlのregionが自分の環境では使えない。先程のyamlを有効なregionとavailability zoneに変える必要があります。
対応
01_base_resources_cfn.yamlにあるTargetRegionとAvailabilityZone1~3のDefaultを有効なus-east-1a, us-east-1b, us-east-1c, us-east-1d, us-east-1e, us-east-1fに変更する必要があります。コメントアウトは、サンプルコードのデフォルト値になります。
AWSTemplateFormatVersion: '2010-09-09'
Parameters:
ClusterBaseName:
Type: String
Default: eks-work
TargetRegion:
Type: String
Default: us-east-1
# Default: ap-northeast-1
AvailabilityZone1:
Type: String
Default: us-east-1a
# Default: ap-northeast-1a
AvailabilityZone2:
Type: String
Default: us-east-1b
# Default: ap-northeast-1c
AvailabilityZone3:
Type: String
Default: us-east-1c
# Default: ap-northeast-1d
...
変更したyamlをアップロードして設定を登録します。
StatusがCREATE_COMPLETEになっているので、これで次へのステップへ進めます。
Redisとは
Redis
Redisとは、データベースやキャッシュ、メッセージブローカーのように使うことができるインメモリのデータストアのオープンソースである。
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker. Redis provides data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams
つまり、ヒープ領域のメモリ内にCRUDが可能なデータベースだと思われる。メモリはストレージよりread/writeが早いので、高速なデータ管理が実現可能になる。Redisの使用例を見ると、ビックデータの一時データ格納先にしたり、ユーザーのセッション管理に用いられることが多いようである。
Redisの起動
今回はdocker環境上にRedisを構築します。以下、簡単な設定のRedisのdocker-compose.yamlになります。
version: '3'
services:
master:
image: "redis:latest"
hostname: master
command: redis-server
docker compose upのコマンドでRedisを起動させます。
# docker-composeの起動 docker compose up # dockerプロセスの確認 docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1b95c0719f0e aa4d65e670d6 "docker-entrypoint.s…" 7 seconds ago Up 3 seconds 6379/tcp redis-master-slave_master_1 # docker上のRedisが起動しているか確認 docker exec -it redis-master-slave_master_1 redis-cli info # Server redis_version:6.2.5 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:cc49a38120feeb6b redis_mode:standalone os:Linux 5.10.25-linuxkit x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:c11-builtin gcc_version:8.3.0 process_id:1 process_supervised:no run_id:efd6d591ad6057fe858f81e74ae066dcb1eadd2b tcp_port:6379 server_time_usec:1627399820470195 uptime_in_seconds:69 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:9868 executable:/data/redis-server config_file: io_threads_active:0 ... (省略)
次に、key-valueを登録させてRedisの挙動を確認します。
# Redisにkey-valueに登録
docker exec -it redis-master_1 redis-cli set str "test"
OK
# 登録されたkey-valueを確認
docker exec -it redis-master_1 redis-cli get str
"test"
# JSON形式でも登録
docker exec -it redis-_master_1 redis-cli set json "{ test: "" }"
OK
# 登録されたJSON形式のkey-valueを確認
docker exec -it redis-master_1 redis-cli get json
"{ test: }"
RedisのMaster/Slave構成の確認
RedisのMaster/Slave構成も確認しておきます。レプリケーションができるようにMaster1台/Slave1台の構成を以下にします。
version: '3'
services:
master:
image: "redis:latest"
hostname: master
command: redis-server
slave:
image: "redis:latest"
hostname: slave
command: redis-server --slaveof master 6379
docker-composeを起動させ、Master用のRedisにkey-valueを登録し、Master/Slave共に登録できているか確認します。
# docker-composeを起動 docker compose up # dockerプロセスを確認 docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 10e64077c5ae aa4d65e670d6 "docker-entrypoint.s…" 19 seconds ago Up 15 seconds 6379/tcp redis-master-slave_slave_1 494d55f1bc71 aa4d65e670d6 "docker-entrypoint.s…" 19 seconds ago Up 15 seconds 6379/tcp redis-master-slave_master_1 # Master用のRedisにkey-valueに登録 docker exec -it redis-master_1 redis-cli set str "test1" OK # Master用のRedisにkey-valueを確認 docker exec -it redis-master_1 redis-cli get str "test1" # Slave用のRedisにkey-valueを確認 docker exec -it redis-slave_1 redis-cli get str "test1"
また、Slaveを更に増やしたい場合はdocekr compose up --scale slave=2とすれば、Master1台/Slave2台の構成を構築することもできます。
所感
会社の商用環境で、Redisが使われていて触ってみたかったので、簡単な設定でRedisを構築してみました。やっぱり、実際に動かしてみた方が理解しやすいので、docker環境で試せるのは楽だな。RedisにはSentinelというHA構成を実現する設定もあるので、自動フェイルオーバーの挙動もやってみたい。
