リードタイムを測るシェルスクリプトを作ってチームの振り返り会を活発にした話 - Classi開発者ブログ
こんにちは。エンジニアのすずまさです。 去年の夏頃にリードタイムの計測を始めてから、振り返りで良い気づきを得られるようになったりリードタイムを減らすアクションが生まれたりと良いことがたくさんあったので、今回はその紹介をしようと思います。 リードタイムの定義 『LeanとDevOpsの科学』では、リードタイムを「コードのコミットから本番稼働までの所要時間」として定義しています。 私たちのチームのリポジトリではブランチ戦略としてGitHub Flowを採用しており、mainへのマージと本番稼働のタイミングが近しいため「PRをopenしてからマージするまでの期間」をリードタイムとして定めて計測しました。 リードタイム計測を始めた動機 私たちのチームでは「チームのスピードがあまり出ていない気がする」という漠然とした課題感がありました。しかし、課題感はありつつも、ではどうするかと言われると具体的なア
コスト削減成功！Amazon Auroraの監査ログをS3に保存する仕組みを構築した話 - Classi開発者ブログ
こんにちは。プロダクト本部Growth部でエンジニアをしている id:ruru8net です。 前回はこちらの記事を書かせていただきました。 tech.classi.jp 今日は前述したSRE留学中にやったことの中の「Amazon Auroraの監査ログをCloudWatch Logsを経由せずS3に保存する」を紹介したいと思います。 前提 前掲の記事にもある通り、弊社のAWSにかかっているコストを調査したところCloudWatch Logsの特にAmazon RDSの監査ログの保存にコストがかかっていることがわかりました。今回は弊社で最も使用しているAmazon AuroraのMySQLのみを対象として、監査ログをCloudWatch Logsを経由せずS3に保存する仕組みを作成しました。 作成した仕組み こちらのオープンソースの仕組みを参考に構築、またLambdaのソースを使いました。
Lambda Extensionと自家版OpenTelemetry Collector - Classi開発者ブログ
こんにちは・こんばんは・おはようございます、エンジニアのid:aerealです。 以前、 実践OpenTelemetry - Classi開発者ブログ で紹介したようにOpenTelemetryを監視フレームワークとして導入しています。 前回の記事ではECSサービスで動くGoで書かれたWebアプリケーションへ導入しましたが、今回はAWS Lambdaの関数からOpenTelemetryを用いてDatadogにトレースを送るための試行錯誤について紹介します。 LambdaからDatadogにトレースを送りたい AWS Lambdaは小〜中程度のタスクを大量に実行することに向いたFaaSです。 汎用性・柔軟性という点ではECSなどのコンテナワークロードと比べると実行環境などに設けられた制約がやや多いですが、その代わりに最適化された実行環境で実行されるのでうまくワークロードと噛み合えばまさに安い
ライブラリのアップデートを自動化した仕組みの紹介 - Classi開発者ブログ
こんにちは！学習動画・Webテストの開発を行っています エンジニアの daichi (id:kudoa) です。 この記事では、最近チームで導入したライブラリアップデートを自動化した仕組みとその経緯について紹介します。 なぜ自動化しようと思ったか サービスを開発するだけではなく、日々の運用も必要です。 その運用業務の1つとして、ライブラリのアップデートがあります。 これはサービスを運用する上では大切なことではありますが、日々ライブラリアップデートのPRをさばき続けるのも大変です。 その時間をできるだけ減らし、その分空いた時間をユーザーへの価値提供や将来の投資に充てるために、今回の自動化の仕組みを作成しました。 この辺りの話は以前勉強会でLTしたことがありますので、興味があればご覧ください。 作ったもの 前置きは長くなりましたが、凝ったものを作ったわけではありません。 作成したものはライブラ
実践OpenTelemetry - Classi開発者ブログ
こんにちは・こんばんは・おはようございます、エンジニアのid:aerealです。 この記事では筆者が開発に参加しているサービスの監視フレームワークをOpenTelemetryへ移行した際の体験を紹介します。 OpenTelemetryとは OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. What is OpenTelemetry? サイトの説明にある通り分散トレースやメトリクス、ログなどの指標を扱う監視フレームワークです。 OpenTracingやOpenCensusなどを継承・統合したプロジェクトと言うと合点がいく方も多いのではないでしょうか。 OpenTelemet
AWS GlueからAWS Batchにしたことで費用を75%削減した - Classi開発者ブログ
こんにちは、最近データエンジニア業を多くやっているデータサイエンティストの白瀧です。 これまでClassiのデータ基盤は、Reverse ETLをしたり監視システムを導入したりとさまざまな進化をしてきました。しかし、Classiプロダクトが発展するとともにデータ量が増加し、これまでのデータ基盤では耐えられない状態に近づいてきました。 そこでデータ基盤の一部（DBからのExportを担う部分）のリアーキテクチャを実施したので、この記事で紹介したいと思います。 概要 Classiのデータ基盤では、Amazon RDSからAmazon S3へJSONで出力し、その後GCS→BigQueryという流れでデータを送り、BigQueryからもBIツールやReverse ETLなどで使っています。詳細は、Classiのデータ分析基盤であるソクラテスの紹介 - Classi開発者ブログを参照してください。
GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 - Classi開発者ブログ
GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 こんにちは @lacolaco です。最近は、先日プレスリリースが出された「学習トレーニング」機能を裏で支えているコンテンツ管理システム（以下内部CMS）の開発に携わっています。 corp.classi.jp この記事では、内部CMSのフロントエンド（Angular アプリケーション）のリリースフローを自動化している仕組みを紹介します。現在のリリースフローの全体像は次の図のようになっています。この中にある Release Please というのが、今回特に紹介したいツールです。いくつか日本語でのブログ記事などもあるので特にマイナーというわけではないと思いますが、多くの場合はライブラリのリリースに使われています。一方、アプリケーションのリリースで使っているケースはあまり発信されてないよう
中立的なGraphQLスキーマの管理 - Classi開発者ブログ
こんにちは、id:aerealです。 今回はGraphQLのスキーマ管理を工夫している点について紹介します。 背景 対象となるアプリケーションは先日プレスリリースが出された学習トレーニング機能を裏で支えているコンテンツ管理システム (以下、内部CMS) で、エンドユーザ向けを含む複数のサービスから呼び出されます。またAngularで書かれたWeb UIを備えます。 内部CMSを開発するチーム内には主にサーバサイドを担当するメンバーと、主にクライアントサイドを担当するメンバーとがおり、どちらもGraphQLを用いた開発経験があります。 この内部CMSはスクラッチから開発を始めており、目指すリリース予定日に対してやることは山積みなのでうまくタスクを分担したい状況にありました。 時と場合によってはクライアントサイドのチームの手が空いていたりあるいは逆になったり、状況は目まぐるしく変わります。 で
GitHub運用委員の紹介 - Classi開発者ブログ
みなさま、おはこんハロチャオ〜。開発支援部所属のid:aerealです。 この記事ではClassiにおけるGitHub運用委員という役割とその仕事について紹介します。 また、この記事はClassi developers Advent Calendar 2022 - Adventarの2日目の記事としてお届けします。 GitHub運用委員とは Classiでは開発のコラボレーションツールとしてGitHubを活用しています。 Webサービスで事業を提供する企業にとって最も重要なソフトウェア資産といえるソースコードをホストするサービスですから不適切に扱えば重大な損害を被ることになりますし、最近はGitHub ActionsというCIサービスも利用できますから一歩間違えれば本番環境で稼働動しているサービスに大きな影響を与えかねません。 当社には情シスやサイバーセキュリティ推進部といった部署が存在し
Classi のエンジニア3名が RubyKaigi 2022 に参加しました - Classi開発者ブログ
はじめに こんにちは！開発本部所属のエンジニアの id:kiryuanzu です。 9月8日(木) 〜 9月10日(土) にRubyKaigi 2022が開催されました。 今回弊社ではシルバースポンサーとして協賛し、3名のエンジニアがオフラインで RubyKaigi に3日間通して参加しました。本記事では参加メンバーによる感想レポートをお送りします。 参加する前 筆者自身は学生時代に何度かオフライン参加を経験したのですが、同行した2名の新卒エンジニアは今回が初参加となりました。行く前にできるだけ RubyKaigi がどんなものか知っておこうということで、開催1ヶ月前から igaigaさんによるプログラム解説を実施していただき、発表される内容の予習を行いました。 他にも、津の気になる飲食店をみんなで探して事前に予約したり、会ってみたい他社のエンジニアさんや OSS開発者の方について話すとい
UNIX 系システムのプロセスに関する社内勉強会に参加しました - Classi開発者ブログ
こんにちは。新卒 1 年目エンジニアのすずまさです。 先日、弊社 VPoT の id:nkgt_chkonk が執筆した process-book の勉強会を修了しました。 process-book は *nix系のシステムにおけるプロセスやシグナルなどについて説明することを目的に書かれました。「プロセスとかよくわかってないからちゃんと知りたいな」みたいなひとたちが想定読者です。 参加する前は UNIX の基礎的な知識も乏しかった私ですが、学びがたくさんあり毎回楽しく参加できたので紹介します。 開催の経緯 Slack でシェルスクリプトの話題で盛り上がったのをきっかけに、プロセスモデルの重要性が話に挙がり、流れでその日のうちに「process-book 読もう会」が誕生しました。 進め方は下記の通りです。 日時: 毎週木曜日 15:00〜15:30 週に 1 章ペースで進める 初めに各章ご
ISUCON12予選 スコア4位相当でしたが失格になりました - Classi開発者ブログ
TL;DR こんにちは。Classi開発部のminhquang4334です。 今年は開発支援部のhenchiyb先輩と一緒に 2回目でyasuoチームとして ISUCON12の予選に参加しました (参考: 1回目で参加したブログ)。 最終結果は予選通過スコアを超えて、 4位/700チーム相当でしたが、SecurityGroupの TCP:8080 ポートがオープンされていたため、レギュレーションに引っ掛かって失敗しました。 以下のチームは予選通過スコアを記録していましたが、追試において失格となっています。 yasuo 環境チェックにおいて、SecurityGroupの TCP:8080 ポートがオープンされていた このブログでは積極的に自分の感想やチームがやったことを共有したいと思っています。 全体的な感想 正直、悲しい気持ち半分、嬉しい気持ち半分で戸惑っています。予選の実施前には、ここま
データ基盤の品質向上への取り組み - Classi開発者ブログ
こんにちは、データエンジニアの石井です。 先日公開した記事「社内向けのデータ基盤から集計結果をReverse ETLしてサービスに組み込んだ話」で、ダッシュボード機能のリリースにより、Classiのデータ基盤が「社内用データ基盤」から「ユーザー影響あるシステムの一部」へ進化した話をしました。「ユーザー影響あるシステムの一部」への進化に伴い、データ基盤の品質担保は必要不可欠です。今回は、データ基盤の品質向上に取り組んだKANTプロジェクトについてご紹介します。 KANTプロジェクト 背景・課題 Classiのデータ基盤がユーザー影響あるシステムの一部になる前、つまり社内用データ基盤だった頃には以下のような課題がありました。 データ基盤の状態把握 マルチクラウドにおけるデータ基盤全体の状態把握ができていなかった データ基盤の実行状態（SUCCESS, FAIL, RUNNINGなど）の把握が、
チームトポロジーを参考に新組織の編成を考えた話 - Classi開発者ブログ
みなさん、こんにちは。開発本部で本部長をしている徹郎(id:tetsuro-ito)です。 Classiでは今年度より組織のあり方を少し見直し、チームトポロジーの考え方も導入してみたので、今回はその過程の話を紹介します。 Classiのこれまでの組織 Classiでは、2020年に起こしてしまったセキュリティインシデントおよび高負荷障害の対策を全社でとるべく、組織のあり方を変えていました。 7月からは、動作しているすべてのコードに対して、チームの責任範囲を明確にしました。また、技術的な課題をそれぞれのチームの責任において改善するような動き方にも変えました。やるべきことが明確（「再建プロジェクト」と「セキュリティ強化」が最優先）で、かつ、チームが主体となって意思決定する形にしたことで、現在は各チームが担当する機能やリポジトリをしっかりとメンテナンスしていく、そんな体制になってきたと思います。
Content Security Policy のレポートを収集するためにやったこと - Classi開発者ブログ
はじめに こんにちは、開発本部所属エンジニアの id:kiryuanzu です。 現在、Classi ではサービスのセキュリティリスクをできる限りなくすために Content Security Policy を導入して脆弱性を検知する仕組みの導入を進めています。 本記事ではこの仕組みを導入する上でどのような手順が必要であり、どのような箇所で苦戦するポイントがあったかについて紹介していきます。 筆者は今まで CSP対応に携わったことがなかったのですが、導入段階の時点で想定していたよりも様々な知識が必要なことがわかり、記事にしたいと思いました。 もし数ヶ月前の自分と同じように初めてCSP対応に関わる人の一助となれば幸いです。 Content Security Policy (通称: CSP) って何? Content Security Policy とは、HTTPヘッダの種類の1つであり、クロ
Classiの技術選定に対するスタンス - Classi開発者ブログ
VPoTの丸山です。本日はClassiがいまのところどういうスタンスで技術選定に臨んでいるのかについてお話しします。これは「いまのところ」のスタンスであり、未来永劫このようなスタンスでいくかどうかというのは定かではありませんが、考え方のひとつとして参考になれば幸いです。 技術選定にハードリミットはかけない 結論から言うと、Classiでは「この技術スタックを必ず使ってください」という制限はかけていませんし、かけるつもりもいまのところありません。その理由は大きくふたつあります。 ひとつは、組織全体の視点でみた時に、技術スタックに関する健全な新陳代謝の機会を奪わないため、もうひとつは、メンバーレベルの視点でみても、複数の技術に触れる機会が成長につながるからです。 新陳代謝を行う機会を奪わない、というのは、どういうことでしょうか。 ひとつの技術スタックを極めていくことにも良い点はあります。ノウハ
Datadogで深夜バッチの失敗アラートを営業時間に受け取る方法 - Classi開発者ブログ
深夜の定期バッチの監視 Webサービスのオフピーク時に重たい処理を実行させるというのは一般的なプラクティスといえます。 特に深夜〜早朝は多くのサービスでバッチ処理を実行させているのではないでしょうか。 Webサービスだけではなく、当然バッチ処理も監視して失敗したらそれを発見し対処したいです。 しかし、失敗を発見しても即座にユーザ影響がないので対応は後でも良いという場合、素朴に監視ルールを作るとバッチが失敗した深夜・早朝にアラートが発報されることになります。 発報されたアラートを見て「これは今すぐに対応してなくても良いな」と判断するのであれば、それは狼少年アラートといえるのではないでしょうか。 悪貨が良貨を駆逐すると言われるように、狼少年アラートがはびこれば良貨のアラートもいずれ無視されるようになってしまうことは容易に想像できます。 Datadogの timeshift 関数でアラートの発報
Mock Service WorkerでAPIをモックして開発をスムーズに進められた話 - Classi開発者ブログ
こんにちは。開発本部 認証連携チームでエンジニアをしている id:ruru8net です。前回はこちらの記事を書かせていただきました。 tech.classi.jp 現在は認証基盤再建というプロジェクトの中で、主にフロントエンド開発を担当しています。この記事ではフロントエンド開発においてAPIのモックのために「Mock Service Worker」を使ったところスムーズに開発を進めることができたので、使い方を紹介したいと思います。 mswjs.io ツールの導入 弊社ではフロントエンドのフレームワークにAngularを採用しているのでAngularでの導入手順を記します。 基本的にはドキュメントの手順通りです。 1. インストール $ npm install msw --save-dev # or $ yarn add msw --dev 2. モックを定義 src/mocks/hand
開発メンバーの保守運用スキルを上げるため実施している朝当番制度の紹介 - Classi開発者ブログ
こんにちは、開発支援部基盤インフラチームの kenryooo です。 Classiでは過去の高負荷によるアクセス障害での反省を踏まえ、エンジニア向けに保守運用スキルを高める施策として、朝当番という制度を運用しています。今回はその紹介をします。 目的 朝当番制度は、下記を目的に運用しています。 Classiのピークタイム(毎朝8:00 - 9:30)に問題が起きた場合、社内向けにスムーズな情報連携を行う サービス品質の継続的な改善 パフォーマンスや監視内容に異常があった場合や、依存している外部接続システムやSaaSのメンテナンス情報などを担当チームへ共有する 担当エンジニアの育成 Classiシステムの全体像の理解 担当外のアプリケーション(リポジトリ)の理解 システム監視の入門(Datadog) インシデントハンドリングの入門 背景と課題 朝当番制度は、下記の背景と課題感からスタートしてい
ISUCON11予選課題の27万点まで練習し新人エンジニアが学んだこと - Classi開発者ブログ
この記事は Classi developers Advent Calendar 2021 の23日目の記事です。 こんにちは、プロダクト開発部の2年目の@minhquang4334です。 今年の8月に、同じ部で3年目の@henchiyb 先輩と一緒に yasuoチームを作り、ISUCON11 オンライン予選に初めて参加しました。参加するきっかけは弊社に業務委託として来てくださっている@soudaiさんからISUCONの話について聞かれて、面白そうなので、チャレンジしてみました。結果はRubyで4万点まで達成できましたが、全体のチームの100/598 位ぐらいで敗退してしまいました。 オンライン予選が終わった後、数百万点を達成したチームはどうやってそこまで出来たのかとずっと疑問でした。各チームの解説ブログを見てみましたが、目を通しただけですぐ忘れてしまい、知見を深く理解できないと思いました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
