2020年振り返り & 2021年に向けて
2020年振り返り
って事で今年1年振り返ってみる
2020年はこの記事から始まりました 当時何も考えずにその場で思い付いたやりたいことリストを書いてたので振り返ってみる
- エンジニア関係でやりたいこと
結果は1/4って所ですかね。
OSSはそんなに有名所ではないけどそれなりのコードを書いていくつかのPRをマージ出来たのでひとまず成功です
その他に関しては全然出来てなかったですね
- その他のやりたいこと
2/5ってところですかね
就職先はちゃんと決めて、本は結構読んだ
読んだ本はこのレポジトリにまとめることにした
12月は謎にエンジニア以外の本にハマってそれなりに読んだ気がする
海外旅行〜〜〜まじで行きたかった…就職したら厳しいだろうなぁぁああ
ダイエットは4月から体重記録することを始めた。笑
英語に関しては映画を英語字幕で見たり、カンファレンスを聞いたり、英会話の体験はしたものの継続して何かをすることは出来なかった
2020年総括
技術的にも成長出来たとは感じられたものの、相変わらず継続力や定量的な成果を出すことが出来てない感が否めない1年間でした
2021年に向けて
まずは早速2021年にやりたいことをまた列挙してみますか
エンジニアリング
- 自分の担当サービスに誰よりも詳しくなる
- 会社で審査ごとにグレードを最低1つ上げる
- AWSの資格を取得する(Associate, Professional)
- ブログを自作する
- 自宅DCを完成させる
- 月1でアウトプットする
- カンファレンスで登壇する
- 海外カンファレンスに参加する(コロナ次第)
その他
- 月2冊本を読む
- TOEIC800点取る
- 映画100本観る
という訳で今年の長期目標を決めてみましたが、去年はこの1年目標をあんまり意識することすら出来なかったので今年は4ヶ月毎に短期目標も定めていこうと思います
如何せん、来年は入社などのライフイベントも大きく変わるのでもっと現実的な目標を決めていこうと思います
最後に
2020年もお世話になりました。来年もよろしくお願いします
Terraform - AWS RDSのengine_versionが見つからない
- Terraformで何も考えずにAWS RDSを作ろうと思ったら以下のエラーで暫くハマってた。
Error: error creating RDS DB Instance: InvalidParameterCombination: Cannot find version 5.7.mysql_aurora.2.07.2 for aurora
状況
- 以下の構成でAurora for MySQLを作ろうとしてた
resource "aws_rds_cluster" "this" {
cluster_identifier = "***"
engine = "aurora-mysql"
engine_version = var.rds_aurora_version
db_subnet_group_name = aws_db_subnet_group.this.name
vpc_security_group_ids = [aws_security_group.aurora.id]
master_username = var.rds_master_username
master_password = var.rds_master_password
enabled_cloudwatch_logs_exports = ["error", "slowquery"]
backup_retention_period = 5
preferred_backup_window = "18:00-19:00"
preferred_maintenance_window = "sun:20:00-sun:21:00"
}
resource "aws_rds_cluster_instance" "this" {
count = 1
identifier = "***-instance-${count.index}"
cluster_identifier = aws_rds_cluster.this.id
instance_class = var.rds_instance
}
これに環境変数var.rds_aurora_version = "5.7.mysql_aurora.2.07.2"を渡して、そのままterraform applyすると何故か最初にも書いたようなエラーで落ちる
Error: error creating RDS DB Instance: InvalidParameterCombination: Cannot find version 5.7.mysql_aurora.2.07.2 for aurora
いや、普通にAWSコンソールでもバージョンあるやん！とか思いつつ調べてたら
engineのデフォルト値はauroraらしい
なのでengine="aurora"のバージョンを見に行って落ちていた
対応策
ここにもあるようにaws_rds_cluster_instanceにもengine, engine_versionを指定することで解決
RDSのTerraformは地味に時間かかるのではまると辛い
resource "aws_rds_cluster_instance" "this" {
count = 1
identifier = "***-instance-${count.index}"
cluster_identifier = aws_rds_cluster.this.id
engine = "aurora-mysql"
engine_version = var.rds_aurora_version
instance_class = var.rds_instance
}
gzipに時間を使い過ぎでは？？
ターゲット
gzipで時間を浪費している人
経緯
データ圧縮する時によく見るファイル形式、.gz
このファイルを生成するのに今までgzipを使っていた
が、結構時間がかかる
pigz
調べていたらpigzなるものがあるらしい
gzipとは違ってマルチコアで処理してくれるので早いらしい
RHELだと
yum install pigz
でインストールできる
検証
とある同一ファイル(約5.7GB)を使って圧縮にかかる時間をtimeコマンドを使って計算してみた
検証機
12CPUs, 12GiB
検証結果
| command | real | user | sys |
|---|---|---|---|
| gzip | 4m42.126s | 4m35.553s | 0m4.971s |
| pigz | 1m1.160s | 5m34.978s | 0m5.872s |
1/4くらいに縮まった
今まで圧縮中にTwitter見てたのに見れなくなってしまった
SRE NEXT 2020参加記
ブログを書くまでがSRE NEXT
ということで、SRE NEXT 2020に参加してきたのでブログを書くことにする
SRE NEXT 2020とは
公式サイトによると
SRE によるコミュニティベースのカンファレンスです。 同じくコミュニティベースのSRE勉強会である「SRE Lounge」のメンバーが中心となり運営・開催されます。
だそうです。
SREとは
じゃあそもそもSREとはなんぞやって話なんですが、こちらもサイトに書いてあるので抜粋
Googleにより提唱された、システム管理とサービス運用における考え方または方法論であり、それらを実践するエンジニアを指します。 SREは、サービスやインフラの信頼性をソフトウェアエンジニアリングによって実現することを目指します。 サービスの信頼性を重視する多くの企業において取り入れられており、近年ますますその広がりを見せています。
会社や個人によって解釈は違うと思いますが、要は開発を加速させつつ、既存のサービス提供に対しても責任を持とうねという話。(だと個人的に理解している)
0次会
とりあえず会場が豊洲って事で朝活してきた。
講演
気合を取り直して会場に行ったら早期入場特典としてエンジニア向けヨガやってた
めっちゃ僕写ってるツイート見つけたので拝借。
ヨガ体験!!🧘♂️🧘♀️#srenext pic.twitter.com/qcaj7eWZvo
— iganari (@iganari_) 2020年1月25日
そしていよいよ講演だったけど全部上げるとキリがないので特に印象に残ったものを抽出して書く
基調講演 : 分散アプリケーションの信頼性観測技術に関する研究
- さくらインターネット研究所の方が基調講演をしていた
最後のトレーシング技術に関しては、データセンタまで考えているさくらだからこその発想という感じがあった。
個人的にも最近低レイヤーやオンプレの勉強をしているのでこの考え方は面白かった。
絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長
さくらインターネットの石狩とGKEの東京リージョンでレイテンシが問題になるのでライブラリを作った
学生個人だとこのレベルで通信や3way handshakeを気にすることがない…笑
- またメルカリではスケールしたときにSREがボトルネックになってはいけないということで組織改編でSREを3チームに分けた
- Core : Database, Mail, etc
- Edge: CDN, Load balancer, etc
- Advocacy : 開発チームの一員
どの組織でもSREがボトルネックにならないようにそれぞれのアプローチで組織改編などで対応しているイメージがあった
freeeのエンジニアは障害から何を学び、どう改善しているのか？
- 障害が起きたときの初動対応を改善
- 障害が起きたときにslackbotで誰を呼んで誰が何をするかのドキュメントが自動生成される
- 後のNewRelicのセッションでも同じようなことをしていた
- 物理的に1箇所に集まるのも効率的
- 障害が起きたときにslackbotで誰を呼んで誰が何をするかのドキュメントが自動生成される
- 割れ窓理論で普段から対応する文化を作っていく
New ReilcのSREに学ぶSREのためのNew Relic活用法
- NewRelicでは最低でも四半期に一度Game Dayと言われるイベントを設けて、自分たちで攻守のチームに別れて攻撃 & 障害対応を行う
- NewRelicのSREがどの様な業務をやっているのかもブログが公開されていたので是非
- ちなみにNewRelicが扱うデータは 20億リクエスト / 分。クエリ対象は1兆イベント超。
ZOZO MLOpsのチームリーディングとSRE@sonots
このセッションでは割とチームマネジメント的な話をされていた。
個人的にはSREに限らずエンジニアの組織として上に立つ人がこんな人だったら働きやすいんだろうなと凄く共感した。
KPTもやっているが、実際にActionまで持って行けてなかったり、調整ごとが先延ばしされて他の作業に支障が出たりする事もよくある。これらを解決出来る環境をチームとして作れればより個人でプロ意識を持つの事にも繋がると思う。
そして、個人的には最後の技術力でぶん殴るがツボ。
エンジニアなんだから最後はソースコードを見て自分で理解・改善していくのが仕事である。まさにその通り。
SRE Practices in Mercari Microservices
- サービスチーム > SREチーム > プラットフォームチーム
- SREはサービスチームが自分たちでサービスをコントロール出来る様にプラットフォームとの間に入って手助けをする。なるほどなぁと言う感じ。
- アラートは意味のあるアラートに
RED(Rate, Error, Duration)でアラートに、USE(Utilization, Saturation, Error)で調査- 顧客に影響のあるものだけをアラートに設定する
- Actionableなアラート設定
- アラートが鳴ったときに誰が何をすればいいかを明確にしておくべき
- 他のセッションでも言っていたがアラートがオオカミ少年になるのが1番危険
- アラートは冬休みの午前3時に起こされても自分が許せるかどうか
改めてSREと言う概念を色々な会社から聞けたのも今回SRE NEXTに来て良かったなと思った。
Webサービスを1日10回デプロイするための取り組み
- 誰でもいつでもデプロイ出来る環境に
- コマンドを叩くだけでデプロイ出来るように
- デプロイを記録・可視化したい
- 履歴をGoogleカレンダーとmackerelに記録する
- ロールバックに備える
- リバート→CI→デプロイは時間がかかるのでデプロイ時に使用しているtarボールをばら撒く機構を作った
前のセッションでも言われてたが、まさにサービスチームがサービスに責任を持てるための橋渡しをするためのSREチームというような仕事内容だった。
余談だが、Elastic Transcoderで毎月家が立つくらいコストかかっていた はまじで衝撃。
最後に
- 流石に1日10セッションを休みなしで聞くと疲れる。帰って9時前には爆睡してた
- 最近のカンファレンスは生中継したり後で資料公開されていたりするから行かなくてもいいかぁと思うこともあるけど、やっぱり現地に行って話を聞くことでモチベーション上げれたり出来るので個人的には出来る限り参加したい
- 次はDevelopers Summit行きます
- 今年は自腹でGoogleIOかAmazon re:Invent行こうと画策中…
- せめてチケット手に入らないかな…
- SREとかに興味のある学生ってどれくらいいるのかな？
- 今回のイベント行っても思ったんだけどSREってあんまり学生いないイメージ
- 今回の発表資料はQiitaにまとまっていたので気になる人は是非
php-fpmのgraceful reloadを試してみる
php-fpmのgraceful reloadが正常に動作してないらしい？ので確認してみる
手順
- とりあえずphp7の環境を整える
- 使用環境はCentOS7
PHPインストール
sudo amazon-linux-extras install php7.2
- 確認
$ php -v
php-fpmの起動確認
$ sudo systemctl start php-fpm $ sudo systemctl status php-fpm
Nginx
/var/www/html/index.phpを作っておく
<?php sleep(10); echo "OK"; ?>
- 大人の事情でnginxからphp-fpmに飛ばす
server {
listen 80;
server_name _;
location / {
root /var/www/html;
allow 127.0.0.1;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
}
}
curl localhostでアクセスの確認をする
Graceful reloadのチェック
- プロセスの確認用に
htopを使った - ブラウザ or
curlでアクセスしているタイミングで以下のコマンドを打つ
$ sudo systemctl reload php-fpm
nginxから502が返ってくる- 全然Gracefulじゃないじゃん…
対策
- ここを参考にphp-fpm(
/etc/php-fpm.conf)のコンフィグをいじる
process_control_timeout = 30
sudo systemctl restart php-fpmをしてから再度同じ様にトライするとnginxからのエラーは返ってこずにGracefulにphp-fpmがreloadされる
自宅鯖(CentOS7.5)1台でk8s環境を構築してみる
オンプレのサーバマシンを買ったのでオンプレk8s運用日記でも書いてみる
その為にはまずは環境を作る！！！
環境
構成
- 題名にもある通り予算の関係で今回は1台の物理マシン上にk8sを構成するのでmaster, workerが同じマシンで動作する
- 誰かお年玉くれたら同じ構成でもう1台物理マシン買うんだけどな…
- 神様がいることを願って賽銭箱(欲しいものリスト)置いときますね。笑
スペック
k8s
- バージョン
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:12:17Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
- CNI
- Flannel
構築作業
- このサイトを元に構築していく
- Master NodeにもPodをデプロイする
- 今回はマシンが1台しかないので仕方なくmaster兼workerにする
- ホスト名は
kubectl get nodesのNAMEに書いてあるもの
kubectl taint nodes <ホスト名> node-role.kubernetes.io/master:NoSchedule-
エラー一覧
kubeadm initが失敗する
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
- 以下のサイトを参考にdockerの
cgroupを変更する
2020年やることリスト
祝・2020年
年明けたし今年やること・やりたいことを列挙してみんとす
エンジニア
- 海外のカンファレンスに行く
- どこかで登壇する
- OSS開発
- アウトプット(ブログ)する
その他
- アジア3カ国行く
- 5kg痩せる
- TOEIC800点
- 就職先決める
- 月1で本を読む
- やるたびにブログ書いて紐付けて行って今年の最後にまた振り返りたい
