kkato.io

2024年の1月に転職してから早くも3ヶ月が経ってしまいました。この3ヶ月くらいは慣れるのに精一杯でした。しかし、次第に環境にも仕事にも慣れてきて、少しずつできることが増えている気がします。少しずつ心にも時間にもゆとりが出てきたので、今更ですが2024年と2025年の目標を決めようと思います。 2024年の目標 2024年の目標はズバリ「Web開発をできるようになる」です。 インフラも半人前なのに何を言っているんだと怒られる気もしますが、この3ヶ月くらいでアプリ側のことを全く知らないのはまずいと痛感させられました。まず1つ目の理由は、インフラチームのミッションの1つに開発者の生産性を上げるというのがあります。例えば、開発者がデータベースを準備したいと思ったら、インフラチームの対応を待つのではなく、開発者自身で簡単にデータベースを用意できるような仕組みを設けておくなどが挙げられます。ユーザー(開発者)が何を求めているのかわからなければ、開発者の生産性を向上させるのも難しいと思います。 もう1つの理由としては、モニタリングの改善や障害対応などの時に、アプリ側の実装を知っておくと事がスムーズに運ぶというのがあります。基本的にモニタリングの設定はインフラチームが行なっており、適切なアラートを設定するというのは意外と難しいです。この時にインフラだけでなく、アプリ側のことも知っておくと抜け漏れが少なく、より適切な閾値を設定することが可能になると考えています。また、オンコールなども基本的にインフラチームが担っており、緊急対応が必要になってもアプリ側のことだからわかりませんでは困ってしまいます。 なので今年はWeb開発力をつけるために以下のことに取り組む予定です。 AtCoder 茶色 緑色 水色 The Odin Project Foundations Full Stack JavaScript Full Stack Ruby on Rails Go言語によるwebアプリケーション開発 2025年の目標 2025年の目標は「幅だし」です。 幅だしとしては、データサイエンスに挑戦してみたいと挑戦してみたいと思っています。昨今AIやLLMなどに注目が集まっていますが、これらの技術を何も知らないと浦島太郎になってしまいそうなので、基礎的な部分は押さえておきたいと思っています。また、データサイエンスには少し遠回りにはなりますが、数学・統計学の土台をしっかりと固めておきたいと考えています。データサイエンスも元を辿れば数学や統計学だと思うので、やっておいて損はないかなと思います。あとは、大学の時に数学を場当たり的に勉強していたので、社会人になったら体系的に学び直したいと思っていた次第です。 2025年に実施したいことは以下のとおりです。 数学検定 準1級 1級 統計検定 2級 準1級 Kaggle Contributor Expert 2026年以降の目標 2026年以降の目標は「深みだし」です。 低レイヤーの技術に興味があるので、自作OS、自作DB、自作コンパイラ、FPGAを使った自作CPUなどをやってみたいと思っています。 あとはOSSコミッタに漠然とした憧れがあるので、何かしらのOSSに対して継続的にコントリビュートしていきたいと考えています。 まとめ 直近2年間の目標を書いてみました。ブログで宣言することによって自分を奮い立たせる「ブログ駆動開発」です。2年後に振り返って、全部達成できていると良いですね。

ウォンテッドリーに入社して1ヶ月経ったので、色々と振り返ってみようと思います。 転職を考えたきっかけ 前職ではややニッチなテーマに取り組んでいたこともあり、そのまま長く居続けても他の会社でやっていけるか不安でした。また、変化が早い時代なので、会社に依存せず個人でやっていけるだけの実力・スキルを身につけたいと考え、もっと技術力を伸ばせるような会社に移りたいと思うようになりました。 企業選びの軸 企業選びは以下の軸をもとに考えました。 自社でサービスを開発・運用している 技術力の高いエンジニアが在籍している 先進的な技術を扱っている 上記の条件を満たすような会社であれば、もっと技術力を伸ばせると思ったからです。 転職に向けて行ったこと インフラエンジニア / SRE職を希望していたので、主に以下のようなことを行いました。 関連する資格の取得 (AWS SAP、CKA) 個人ブログでの発信 簡単なWebアプリの作成 前職でPostgreSQL、Kubernetesを触る機会があったものの、AWSやTerraformの経験、それに本番環境の運用経験がなく苦労しました。実務での経験不足を補うために、AWSの資格を取得したり、個人ブログで今まで学んだことのアウトプットなどを行うようにしました。また、SRE職などだと自動化のツールなどをGoで書くこともあると思ったので、Goで簡単なTo-doアプリを作成したりしました。 ウォンテッドリーへの入社を決めた経緯 ウォンテッドリーへはスカウト経由で入社しました。（Wantedly Visitに登録したら、ウォンテッドリーからスカウトが来てびっくりしました笑）カジュアル面談で話を聞いていると、PostgreSQLやKubernetesなど今まで培った経験を活かしつつ、新しい挑戦ができそうだったので、選考を受けてみようと思いました。 選考を受ける前だったか、1次面接の後だったか覚えていませんが、Engineering HandbookとCulture Bookをいただきました。まず、開発や会社の文化に関することがこのような形にまとめられているのが素敵だと思いました。そして、内容に関してもエンジニアリングに対して真摯に向き合う姿勢やエンジニアにとても理解のある会社だということが伝わってきて、こんな会社で働いてみたいと思うようになりました。（個人的にはCulture Bookの「変わるエンジニアの定義」が好きです。) また、2次選考として 1 day インターンに参加させていただきました。わずか1日のインターンシップではあるものの、チームメンバーがどんな人なのか、日々どんな業務に取り組んでいるのかなど実際に働くイメージがつき、その後安心して入社することができました。 入社してからの感想 毎日分からないことだらけですが、その分学ぶことが多くてとても充実しています。周りのエンジニアの方々は技術力が高くて、尊敬できる方ばかりです。 オンボーディングに関しては、研修や社内のドキュメントが整備されていて、スムーズに環境に馴染むことができました。分からないことがあるとすぐに聞ける雰囲気があり、ちょっとしたことでもSlackやHuddleで相談できて大変ありがたいです。週2出社なので、対面でのコミュニケーションもできて良い感じです。 びっくりしたことは、会議室の名前がジョジョの奇妙な冒険からつけられていること、白金台のランチの選択肢の少なさ、あとはエンジニアの1割がDvorak使いということですかね笑　今後ウォンテッドリーで取り組みたいこと 今後取り組みたいことは以下の通りです。 Kubernetes, PostgreSQLなどのアップグレード インフラの性能監視・運用改善・障害対応 Goを用いたツールの開発 前職だと実運用を経験していなかったので、システム基盤のアップグレードを経験したいという思いがあります。同様に、性能監視や運用改善、障害対応などインフラエンジニアとして求められている基本的な業務も一通り経験してみたいです。また、ウォンテッドリーのインフラチームは様々なツールをGoで実装しているので、それらの実装を理解し改善していけるだけの力をつけていきたいです。 上記以外にも直近不足している知識(NW、AWS、Terraform、Gitなど)が多いので、日々精進していく所存です！

Kubernetes上でAlertmanagerがちゃんと通知できるか、どんな内容が通知されているのか確認してみようとすると、連携するためのSlackが必要であったり、Emailを送信するにもメールサーバが必要だったりと、意外と気軽に試せないということがありました。 なので、今回はwebhookの機能を使ってNginxにリクエストを飛ばし、リクエストの内容をログから確認してみようと思います。 webhookとは? Alertmanagerのreceiverには以下が指定できます。 Email Opesgenie PagerDuty Pushover Slack AWS SNS VictorOps Webhook Wechat Telegram Webex Webhookとは特定のエンドポイントに対してHTTP POSTリクエストでアラートの情報を送信するというものです。 外部サービスではないので、自分自身でエンドポイントを用意し、自分自身で後続の処理を実装する必要があります。 例えば、以下のように設定します。 receivers: - name: "nginx" webhook_configs: - url: 'http://nginx-svc.default:8080/' webhookの連携先としてnginxを使う 今回はwebhookの連携先としてnginxを使用します。 nginxを使って実現したいことは以下のとおりです。 エンドポイントを用意する リクエスト内容を確認する nginx.confの初期設定をベースにしていますが、そのままだとリクエスト内容を確認することができないので、設定を追加しました。 log_formatで$request_bodyを指定し、/にアクセスした時に$request_bodyがログとして標準出力に出るように設定しています。 しかし、$request_bodyを有効化するにはproxy_passなどの後続処理が必要になります。なので、proxy_passで/trashというエンドポイントにリクエストを転送し、/trashで特に意味のない処理(1x1ピクセルのgifを返す)をしています。 The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer. http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_body user nginx; worker_processes auto; error_log /var/log/nginx/error.log notice; pid /var/run/nginx....

CronJobは、指定したcronフォーマットに基づいて定期的にJobを実行するという機能です。 主にバックアップの取得やメール送信など、定期的な処理を実行する際に便利です。 一方で、CronJobが失敗した際にどのように検知すべきかについては、あまり情報がありませんでした。 なので、今回はそちらについて考えてみたいと思います。 kube-state-metricsを活用する kube-state-metricsとはKubernetesクラスタ内のリソースの状態をメトリクスとして提供してくれるというものです。 kube-state-metricsではCronJobやJobの状態をメトリクスとして取得することができます。 この方式採用している記事が多かったので、こちらで検討を進めてみたいと思います。 ※記事 https://medium.com/@tristan_96324/prometheus-k8s-cronjob-alerts-94bee7b90511 https://www.giffgaff.io/tech/monitoring-kubernetes-jobs どのメトリクスを使い監視するか CronJobはcronフォーマットで指定された時刻にJobを生成し、そのJobがPodを生成するという3層の親子構造になっています。 また、CronJobとJobの関係は1対多で、JobとPodの関係は1対多になります。 Jobが完了するのはcompletions個のPodが正常終了した場合、もしくはbackoffLimit個のPodが異常終了した場合に限ります。 completions completions個のPodが成功すると、Jobが完了したとみなされる デフォルトは1 backoffLimit 失敗したと判断するまでの再試行回数で、この回数を超えるとJobは失敗とみなされる デフォルトは6 そして、アラートを上げたいのはJobが失敗した時です。言い換えると、backoffLimit個のPodが異常終了したときにアラートを上げるということになります。 何個のPodが異常終了したのか監視することも可能だと思いますが、ここではJobのステータスを監視するのが適切かと思います。 メトリクス 対応する項目 説明 kube_job_status_succeeded .status.succeeded Jobの管理下で正常終了したPodの数 kube_job_status_failed .status.failed Jobの管理下で異常終了したPodの数 kube_job_complete .status.conditions.type Jobが成功したかどうか kube_job_failed .status.conditions.type Jobが失敗したかどうか 参考: https://github.com/kubernetes/kube-state-metrics/blob/main/docs/job-metrics.md Jobに関するメトリクスは複数ありますが、この中でも特にkube_job_failedを使ってアラートを上げるのが良さそうです。 以下の設定だと、Jobが失敗したときにアラートが上がります。 kube_job_failed > 0 アラートが発火し続けてしまう問題 失敗したJobは削除されずに残り続けるので、アラートが発火し続けてしまいます。 なので、JobのttlSecondsAfterFinishedを設定し、数分後にJobが削除されるようにします。 ttlSecondsAfterFinished 指定秒後にJobを削除できる CronJobのfailedJobsHistoryLimitを設定するという方法も思いつきましたが、0にしてしまうとそもそもアラートが上がらないと思うので、こちらは1のままにしておきました。 failedJobsHistoryLimit 失敗したJobを指定個数分残しておける デフォルトは1 まとめ 今回はkube-state-metricsを活用して、CronJobが失敗した時のアラートを設定しました。他にもっといい方法をご存知の方は教えていただけるとありがたいです。

AWSでEC2インスタンスを建てると、デフォルトで"ec2-user"という名前のユーザが作成されます。公開鍵認証なので高いセキュリティレベルが担保されており、ユーザ名が知られていても特に問題はないと思います。しかし、より安全にEC2を使用するためにデフォルトのec2-userを削除し、新しいユーザでアクセスできるように設定したいと思います。よくこの設定方法を忘れてしまうので、備忘録として残しておきたいと思います。 ちなみに公式でもこんな風に書かれています。 デフォルトのユーザーを使用するのが多くのアプリケーションに適しています。ただし、個人が自分のファイルとワークスペースを持つことができるように、ユーザーを追加することを選択できます。さらに、新しいユーザー用にユーザーを作成することは、デフォルトユーザーへのアクセス権を複数のユーザーに (経験のないユーザーも含めて) 与えるよりも、はるかに安全です。これはデフォルトのユーザーが不適切に使用された場合、システムにさまざまな損害を与える可能性があるためです。 ec2-userを削除するまでの流れ useraddコマンドを使い新しくユーザを追加します。追加したユーザにsudo権限を付与します。また、追加したユーザのパスワードも登録します。 ssh -i ~/.ssh/秘密鍵の名前 ec2-user@EC2インスタンスのパブリックIP sudo su - useradd -m ユーザ名 usermod -aG wheel ユーザ名 passwd ユーザ名 追加したユーザのホームディレクトリにauthorized_keys(公開鍵の情報)をコピーし、適切な権限を付与します。 mkdir /home/ユーザ名/.ssh cp /home/ec2-user/.ssh/authrized_keys /home/ユーザ名/.ssh chown -R ユーザ名:ユーザ名 /home/ユーザ名/.ssh chmod 700 /home/ユーザ名/.ssh chmod 600 /home/ユーザ名/.ssh/authorized_keys その後新しく追加したユーザで接続し直し、接続できることを確認したら、ec2-userを削除します。 exit ssh -i ~/.ssh/秘密鍵の名前 ユーザ名@EC2インスタンスのパブリックIP sudo userdel -r ec2-user