モニクルのSREチーム形成期を振り返って
はじめに モニクルでSREをしているbeaverjrです。 この記事では、私が2023年7月に弊社初の専任SREとして入社してからの経験を振り返り、行ってきたこと、実際に直面した挑戦やそこから得られた学びを共有します。 今回は技術的な面ではなく、SREチーム・個人としてどのように成長してきたか、その過程でどのようにSREのイネーブリングの取り組みを進めてきたかに焦点を当てて紹介したいと思います。 ※イネーブリング：この文章では組織にSREの原則と実践を広め、根付かせることを目指す活動を意味します。 SREチーム立ち上げの背景 弊社はエンジニア全員がフルサイクルエンジニアとして活躍できる組織を目指しています。このビジョンの実現に向け、2023年7月にSREチームが設立されました。 立ち上げからの取り組み①：チームビルディング チームビルディングの過程では、まず共通の目標とビジョンを確立するた
Biomeはいいぞ
モニクル Advent Calendar 2023の3日目です。 どうも@circled9です。 モニクルで社内向けの財務システムでTypeScriptのコードを読んだり書いたりしています。 最近Biomeに勢いがあってうれしいので、lintとformatのことをつらつらと書いてみます。 lintとは まずはlintとはなんでしょうか。 Wikipediaには以下のように書かれています。 lint とは、主にC言語のソースコードに対し、コンパイラよりも詳細かつ厳密なチェックを行なうプログラムである。静的解析ツールとも呼ばれる。以下に挙げるように、コンパイラではチェックされないが、バグの原因になるような曖昧な記述についても警告される。構文（シンタックス）レベルのチェックだけでなく、意味（セマンティクス）レベルのチェックまで実行するものもある。 https://ja.wikipedia.org
Google Cloudの障害情報をプロジェクト単位でキャッチしたい!! Personalized Service Healthを使ってみた
書こうと思った経緯 入社後、業務でGoogle Cloudを本格的に使い始め、Google Cloud自体の障害情報をいい感じにキャッチする方法がないかな〜〜と思い始めました。 （´-`）.。oO（AWSのAWS Health Dashboardみたいな、プロジェクト単位で影響がある障害情報を確認できたり通知できるサービスがあればいいのに... ...ていうか知らないだけでそもそもあるのでは!?!?) と気になって調べたところ、いいタイミングで公開されたこちらのサービスに辿りついたため、実際に使ってみました。 主な機能 ダッシュボード コンソールからGoogle Cloudのインシデント一覧の詳細を確認できます。 インシデントがプロジェクトに与える影響度がわかるのがミソだと思います。 アラート 新しいインシデントの発生や既存のインシデントの更新などのシナリオに対して、アラートを設定できます
Next.jsのMiddlewareで認証が必要なCloud Runと通信できるようにする
弊社のとあるプロジェクトでは以下の図ような構成でプロダクトを開発しています。（とても簡略化しています） フロントエンドからGraphQLを利用する場合には、Next.jsのMiddlewareを用いてバックエンド（GraphQL Server）との通信をプロキシさせています。 バックエンドはフロントエンドとは別のCloud Runで動作していますが、 Cloud Runのデプロイ時に --no-allow-unauthenticated フラグを付与し、認証を必要にしているといった構成になります。 このフラグを付与することでバックエンド用のCloud Runに対するroles/run.invokerロールを付与したサービスアカウントで認証することでしかバックエンド用のCloud Runと通信できないようにすることが可能となり、セキュリティを向上させることができます。 今回Middlewar
GraphQLクライアントがリクエストするURLにoperationNameを付けると便利です
GraphQLのクエリやミューテーションはJSONエンコードされた本文をHTTP POSTでサーバに送ることで実行されます。 すべてのクエリやミューテーションは同じエンドポイント(/graphql等)に対してPOSTされるため、特別な対応をしない限り、ログには「クエリ or ミューテーションどちらなのか」「どんな内容か」などの情報が記録されません。 簡単な設定だけでログを見てざっくりリクエストの傾向がわかるようにできると便利ですよね。 エンドポイントにoperationNameを付与する 例: query FooBarQury を実行した場合 -> /graphql?operationName=FooBarQuery 上記のようにしてクエリやミューテーションの名前を operationName としてリクエストURLに付与します。 具体的な情報はもちろん本文に含まれるため、細かな分析はでき
開発チームの技術ブログまとめサイトを作って定期デプロイを設定した
私が所属する株式会社モニクルの開発チームでは、業務時間内に各個人の技術ブログを書いてもよいことになりました。2022 年 7 月現在の時点では、きちんとスプリントの中でストーリーポイントを付けたタスクにして、時間を確保することが推奨されています。 アウトプットの習慣があるメンバーが多く見えるチームというのは、対外的にも魅力を説明しやすいです。今後のソフトウェアエンジニア採用を円滑に進めていくための施策の一環として、アウトプットを推奨していきます。 技術ブログまとめサイトはじめました ということで、メンバーの技術ブログをまとめた、monicle developers というサイトを作りました。 テンプレートとしてcatnose99/team-blog-hubを使わせてもらいました。RSS を登録しておくと最新の記事をまとめて表示してくれる素敵なアプリケーションで、Ubie Engineers
Terraformを使ってインフラと触れ合いたいぞ
$ brew install tfenv $ tfenv --version $ tfenv list-remote $ tfenv install 1.3.0 $ tfenv use 1.3.0 流れ まずはterraformでインフラを作ってみるときの全体的な流れの確認 アーキティクチャを設計する。 設計できたらTerraform化。最も依存されるコンポーネントから作る。 ルートモジュールを作って、.tf 拡張子のファイルを作って、プロバイダーやリソースなどのConfigurationを定義して terraform initする。terraform init はTerraform 構成ファイルを含む作業ディレクトリを初期化してくれて、必要なプラグインや子モジュールのインストールをしてくれる。 terraformのコードを書き終えたら、terraform plan を実行する。terra
React Router v6.4はClient Side Remix
React Router v6.4 が、破壊的変更を伴わないマイナーバージョンアップながら、機能追加の内容としてはかなり新しい世界観を追加してきたので、5 分くらい眺めて気づいたことをメモしておきます。 Routing と Data Loading/Mutation の統合 まずはリリースノートがこちら。 そしてリリースノート内に貼り付けられている動画がこちら。 1:45 しかない動画なので、動画を見ていただければこの記事はあんまり読まなくてもいいかもです。 さて、動画内では、次の 2 つの機能を <Route> コンポーネントへと統合した話題が語られています。 データ読み込み（Data Loading） 0:00〜 0:28〜 エラーハンドリングの話題もあり データ更新（Data Mutation） 0:52〜 <Route> に統合された API は、ざっくりと次のような形です。 <R
VercelのMiddlewareを使って非Next.jsプロジェクトにBasic認証をかける
プロトタイピングしたツールを、身内へ気軽に公開したくなることってありますよね。Cloudflare Accessみたいなちゃんとしたソリューションをイチから導入するほどのモチベーションはなくて、Basic 認証が付いてればまあいっか、くらいの気軽さのやつです。 近頃だと、筆者はフロントエンドプロジェクトを Vercel にデプロイすることが多いので、Vercel について調べてみました。 Vercel には、主に Next.js から使うことを前提とした、Edge Middleware という仕組みがあります。これはページの表示前に割り込む形で通信結果に介入できるので、Basic 認証を実装できそうです。 Next.js を使う場合はこれでいいのですが、目的次第ではCreate React AppやViteのような、小さめのツールチェインでプロトタイピングをしたいケースもありますよね。そう
Rails エンジニアが Prisma に入門する：開発フロー編
前回 の続きです。 はじめに 前回チュートリアルをやりながら Prisma を一通り触ってみたわけですが、実際の開発（普通の Web アプリケーションを想像してください）となると、目的の機能を作るためにデータストアのレイヤーでは以下のようなことをよく行います。 新しいモデル（テーブル）を追加 カラムを追加 関連を追加 NULL/NOT NULLなど制約を変更 などなど。変更や削除は、運用を考えると取り回しを別途考えなければいけないので一旦触れません🙇♂️ いきなりつまづいた チュートリアルでは prisma migrate dev を使ってマイグレーションファイルを作り、DBに反映することを学びましたし、Rails でも同様の思想で開発するのでこれが当たり前かと思ってしまいましたが、素振りをしている中でいきなり課題にぶつかりました。 Rails ではマイグレーションファイルを作って試し
あらためてデコレーターを学ぶぞ
はじめに NestJS入門してみようとしたら、アットマークから始まる記述を知らなかったので調べたことを簡単にまとめた記事です（デコレーターのことよくわかってなかった） デコレーターの仕様は、過去にいろいろと変わって現在に至っているようでしたが、ようやく最近 ECMAScript では Stage 3 になり、TypeScript では今も実験的なサポート experimentalDecorators を使えますが、バージョン 4.8 で TC39 の Decorators を実装することが検討されているようです！ この記事は、TypeScriptのドキュメントのサンプルコードを動かしてみたり、あらためてNestJSのコード読んだりしてみた感想を書いてみました。 最近のデコレーターを追えてない、NestJSを動かしてみようとしたらデコレーターってなんぞや、となったかたの参考になれば幸いです。
SPFレコードをフラット化してルックアップ数制限を乗り越える
includeを使うことによって、includeした先のレコードもさらに確認することになり、SPFレコードが示したいIPアドレスに辿り付く前に10回の制限を越えてしまいます。 対処方法 余計なSPFレコードのエントリを削除する 使っていないエントリが放置されているならどちらにせよ削除したいです。 SPFレコードをフラット化する includeによってネストしてしまうことで余計なDNS参照が加わってしまうので、あらかじめ展開することで参照回数を削減します。 includeで指定されたレコードを展開していく例: # 元々のレコード v=spf1 include:_spf.firebasemail.com include:_spf.google.com -all # 展開 v=spf1 include:sendgrid.net include:_spf.google.com include:_n
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
