こんにちは、データプラットフォームチームでデータエンジニアをやっている滑川(@tomoyanamekawa)です。
データプラットフォームチームはデータAI部のメンバーで構成されていて、データ分析基盤を中心としたデータ活用に関するシステムに責務を持つチームです。
データAI部が出来てから3年が経ち、データ分析基盤を今の形で運用をして1年半が経過しました。
データエンジニアの採用活動の中でデータ分析基盤を紹介する必要がある一方、説明コストが高く困っていました。
そこで今回は「ソクラテス」と呼んでいる社内のデータ分析基盤について紹介します。
（データAI部ではシステム基盤に哲学者の名前をつける慣習があります。）
はじめまして。Classi株式会社 UXデザイン部でUXデザイナーをしている原田です。
私は2021年3月に北海道旭川東高等学校（以下、旭川東高校）さまにて「描いて思考力を深める『ラクガキ講座』」なる講座の講師を高校生の皆さん向けに開催いたしました。個人的にとても楽しく、充実した時間を過ごすことができたので、今回は私がUXデザイナーとして場の作り方や講師として意識したことをお話します。
実施した背景と講演レポートはこちらに詳細な内容が掲載されておりますので、ぜひご覧ください。
旭川東高校 「描いて思考力を深める ラクガキ講座」レポート | Classi
振り返ってみると、私はこんなことを意識し実行していました。
１）先生とのヒアリングを通して、やる目的とゴールを明確にする
２）高校生でも気軽に参加しやすいようにハードルを下げる
３）Miroを使ってインタラクティブな仕掛けを用意する
４）偶発性やハプニングを利用し演出する
それぞれどういうことなのかご紹介していきたいと思います。
このお話を持ちかけてくださった先生と最初のZoomMTGで「参加いただく生徒にどのようになって欲しいのか」をまず話していただきました。こちらがその当時の一番最初のメモ書きです。
はじめは拙い内容ですがここに想いが凝縮されています。きっかけは「グラフィックレコーディング（以下、グラレコ）の講座をやりませんか？」というお誘いでしたが、ヒアリングをしてみると必ずしもグラレコをやる必要はありませんでした。そこで実施する目的やゴールイメージを対話し丁寧に解きほぐし、ビジュアルシンキングの考えに触れることで生徒の思考力を深める一助になるという思いでアイデアをお互い出し合い、画面投影でNotionをリアルタイムで編集し下記のように「目的」と「ゴール」を設定しました。
目的とゴールが定まったので、次は教室内に掲示する告知チラシの作成になります。
今回の講座は希望者制のため、生徒の皆さんにとって興味のある内容でなければ参加いただくことは到底できません。ソレはコワイ。なので、なるべく多くの方に関心を持っていただけるような工夫をする必要がありました。掲載内容を色々考えてみて、実際に掲示されたチラシがこちらです。
ここで工夫したのは「自分でも大丈夫という意識」と「近所のねえさん感を出す」ということでした。私は学生とも先生とも異なる立場ですが、そういう立場だからこそ学べることがある！と思い気さくな感じを随所に散りばめてみました。その甲斐もあったのか（？）、当日は55名の参加があり、具体的にはこういう箇所で参加ハードルをさげる工夫ができていたかなぁと思います。
当日はZoomを利用したオンライン開催で実施していました。 黒板やホワイトボードを活用した動きのあるスクライビングができないため、資料をすべてMiroで作成し、PCで画面を共有、iPadで手描きで補足するという行為をしていました。
このように既存の内容に線を引くという行為だけで生徒の皆さんの目を引きますし、なにより私がこのスライドを用いて何を伝えたいのかがより明確になります。異なる場所にいても手描きの線が同期的に出現することによって、この講座の橋渡し的なつなぐ存在になっていたのではないかと個人的には感じます。
講座のプログラムはもちろん事前に台本のようなタイムスケジュールを用意し進行をしていきますが、偶然の出会いや、その場で初めて遭遇するようなことをうまく活用すると場そのものが停滞せず活性化していきます。講座自体は私が一方的に話すだけではなく、生徒の皆さんも実際にトレーニングとして色々描いてみてそれをグループ内でシェアをするということをしていました。そこで意識していたのは予定調和で進むのではなくその空間にあるものや突発的に出たワーディングを使い臨機応変に行動し、場そのものに動きをもたせることです。例えば、発表する順番を私の気分でいきなり決めたり（ひどい）、生徒の１人が代表で発表する際も、講師が指名するのではなく目にとまった生徒さんから生徒さんに指名いただくといったことをして、適度な緊張感もありつつも、常にドキドキ、わくわくできるように努めていました。
このような状況下でもあるため、普段なかなか高校生の皆さんと接する機会もなかったのですが 今回のことを通じて私自身が学ぶことが多くあり、旭川東高校のみなさまには感謝の気持ちでいっぱいです。 開催された日は緊急事態宣言中でもあったためオンライン開催にせざるを得なかったのですが、状況が収束したらリアルに対面をしてパワーアップした講座ができたらいいなぁと思います。
開発支援部基盤バックエンドチームのみんなの頼れるお兄さん 
id:Soudai です。Classiでは例年新卒採用を行っており、新卒研修の一環として今年からそーだい塾を行いました。当日の資料はこちらです。
この記事では当日の資料にはない部分で、研修中に触れた内容について解説していきます。
研修中の最初の質問は「変更に対する可用性をどこまで許容しますか？」でした。 質問を噛み砕くと どこまで設計にこだわりますか？ という質問でもありました。結論としてはYAGNIを言い訳に使わず、最大限考え抜くべきとした上で私なりのアドバイスをしました。
最初から最高の設計が思いつけば問題はありません。しかし、考えがまとまらないときにどこまで考え抜くかは悩ましい問題です。 そこでアドバイスとして次の2つをしました。
諦める条件を先に決めてから考えましょう。例えば納期から逆算して時間制限を設ける、特定のドキュメントを読んでみて理解を深めた後に思いつかなかれば諦める、などです。今回の場合、15分間悩んだら相談する、などを例にあげて『最初のうちは悩んでもなかなか答えはでないから早め早めに諦めよう』と伝えました。立場や課題などのケースバイケースではありますが新卒1年目でなかなか答えにたどり着けないのは当たり前のことです。どんどんチームを頼りましょう。
そしてチームを頼るときは質問の仕方を工夫しましょう。自分がアイディアを持っている場合はそのアイディアを、そもそもアイディアすらない、暗中模索であるならばその状態を正確に伝えましょう。
諦めるまでの間、最大限考えても行き詰まることはあります。そんな時は考え方を変えるということが大事です。例えば以下の具体的なアドバイスをしました。
やりたいことを考えるときに制約から考えることで道筋が見えてくることもあります。 また考えがまとまらない時は認知している課題のスコープが大きすぎたり、本質から遠すぎたりすることもあります。そしてリリースしてみて気付くことも沢山あります。これらの手法は経験によって最適な方法を判断することが多くあるため、まずは早めに相談してチームで考え方の検討から相談するのが良いでしょう。
AプランとBプランがあったとき、どっちが良いか？という判断が必要です。ではどうやって選ぶのでしょうか。
特に3つ目は重要で 結果がすぐわかることはとりあえず試し、結果がわかるまでに時間がかかることは丁寧に判断する ことが肝要ですよっと言う話もしました。
だからこそ小さく始めたり、解決したいスコープを知るためにも 作る前の段階からサービスに関わる ということも大事ですよと言う話もしました。
40分程度の発表に対して50分程度の質疑応答と大盛りあがりのそーだい塾でした。 ここで紹介した話も質疑応答の中のほんの一部ですし、次回のそーだい塾も盛り上がること間違いないでしょう。
もし、参加したい！と思った方のためにこちらのリンク紹介しておきます*1。
*1:録画あるので入社すると見ることも出来ます
こんにちは、Classi株式会社2020新卒エンジニアのid:kiryuanzuです。 以前寄稿した記事ではClassiの部活動の一つであるCTF Cafeについてお話しましたが、今回は2020新卒として印象に残ったことをテーマとして、自分が現在配属している「学習記録チーム」で初めて経験したプロジェクトとチームで日々行なっていることについて紹介したいと思います。
7月まであった新卒研修が終わり、学習チームに配属された筆者はチームの先輩と共にECS化に取り組むことになりました。その内容に関しては、自分と同じくECS化に取り組んでいた同期の小川が丁寧に紹介しているのでぜひご一読ください。
10月頃にはリリース作業まで無事終わり、新しい課題に着手する上で新しく学習チーム内で作られた小さなチームに加入することになりました。 そのチーム名は「借金返済チーム」です。名前通り「学習チーム内の技術的負債をどんどん返済していくぞ!」という目的で結成されました。
Classiでは現在、プロダクト再建の試みが沢山行われており、その動きに加われることは大変興味深く、新卒の人間がどこまで貢献できるか心配な面もありましたが、できるだけ頑張っていこうと当時感じたのをよく覚えています。
自分以外のメンバーの中にはClassiのプロダクトを以前から長く触れているシニアエンジニアの方、SoftBank(SB)から出向で来られた新卒3年目の方と未経験中途で入社された2年目の方がいます。私含めた3人はジュニアクラスのエンジニアという比較的若手が多い構成です。
借金返済チームにして加入してすぐ、技術的負債を返済するための大掛かりなタスクをチーム全員で任されることになりました。 スケジュール上の都合として、10月からスタートし12月までに終わらせる方針で動くことになり、まずは調査で判明した膨大なタスク量を切り分けてタスクを消化するための行動を起こすことから始まりました。
具体的には、GitHub Projectsでタスクを一つ一つ切り分けて担当者を決め、カンバン方式で管理するようし、Googleスプレッドシートでバーンダウンチャートを作成して日毎のタスク消化量と目標の消化量を可視化させながら進めるようにしました。そのようにして、チーム内で今課されている膨大なタスクの「見える化」を行うようにしました。
進めていく中で、スケジュール的に不安を感じる時期もあり、その時はチーム外から助っ人を呼んで対応を行いなんとか軌道修正することができました。このような動きができたのも、膨大なタスク量の消化具合を可視化させることで進捗管理する意識が高まったことで、適切な判断を行うことができたのではないかと考えています。
このプロジェクトを経験したことで、チーム開発の中でどのようにしたら効率よく物事を進めていくことができるのかを以前より考えられるようになりました。
今振り返ると、膨大なタスクを地道に消化していく様はまさに地道に借金を返済していく様子と似ていたのではないかと思います。自分含めてチーム内では「借金返済チーム」という名前を大変気に入っていて、「今日も頑張って借金を返済していきましょう!」を合言葉にモチベーションを上げながらみんなでプロジェクトを無事終わらせることができました。
このような大きめのタスクが終わった後、学習チームの中にあるそれぞれのサービスごとに技術的負債を返済していく方針に変わることになり、借金返済チームは、学習チーム全体の技術的負債を返済するチームではなく一番関わることの多かった学習記録サービスを担当するチームとして生まれ変わることになりました。
大型のプロジェクトを経てチームメンバーとの絆は深まりましたが、さらにチームとして切磋琢磨していきたいと考え、様々なアプローチを現在行なっています。 具体的には、毎朝15分の読書タイムを設けて読後に感想を話し合う会や、「Angularまなび会」と題してフロントエンドの技術を勉強する試みをもくもく会形式で週一で行なっています。
また、チームメンバーの気分や調子をできるだけ把握しておこうと決め合って朝会の時に今日のタスクを話した後に自分自身の今の気分を伝え合う試みもしています。
このような取り組みを続ける中で、お互いがしたインプットを共有し合うことでみんなで新たに学びを得ることができたり、チームメンバーのパーソナリティを理解し合おうとする空気が作れているように思います。
先ほども述べましたが、みんなで一緒に学んで成長していこうといったような空気があり、新卒という立場としてもこのような環境に身に置いて学べることは大変価値のあることだと感じています。そして、その状況を優しく見守ってアドバイスしてくれる先輩エンジニアの存在もあり良いチームになっていると常々感じています。
4月からはついに入社2年目に突入し、新しい動きや気付きが求められるようになっているのを実感する日々です。今も現チームで業務に励む日々ですが、今後は組織の体制の変化などにより、チーム異動等のイベントで今の環境から大きく変わることもあるかもしれません。そのような様々な状況に出くわす中でも、エンジニアとして成長し続けられるよう頑張っていきたいと思います。
こんにちは。2020年4月にClassiに新卒入社し、エンジニアをやっている小川です。 私が入社した後に、各プロダクトの実行環境をEC2からECSにリプレイスしていく取り組みが始まりました。 AWSに触れた経験が全くありませんでしたが、私もこのECS化に取り組み、無事にリリースすることができました。 私がこのECS化を通して良かったと思うこと・学んだこと・感じたことを、新卒の視点で振り返ろうと思います。
これまでのEC2での運用ではデプロイフローが複雑になっており、機能改善のためのリリースのサイクルが遅くなってしまっているという課題がありました。 教育現場の状況が日々変化する中で、ユーザからのニーズに素早く対応する必要があります。
ECS化することで、例えば次のようなメリットがあります。
また、ECS化のタイミングで既存のデプロイフローの見直し・改善を行うことで、次のようなメリットもあります。
このようなことから結果的にリリースサイクルを改善することができるため、アプリケーションの実行環境をEC2からECSにリプレイスする取り組みが始まりました。
Classiでは機能別にプロダクトが分かれており、並行して各プロダクトのECS化が進められました。 私は同じチームのエンジニアの先輩と2人でペアを組み、ポートフォリオという機能のECS化を担当しました。
ECS化を進める上で良かったと思うことは次の2つです。
作業はペアプロで行いましたが、基本的にドライバーを自分に任せてくださいました。 AWSはおろかインフラも何もわからなかったので、ちゃんと進められるか不安がありましたが、先輩が作業手順や作業内容を丁寧に教えてくださいました。 そのおかげで不安は消え、1つ1つ理解しながら進めることができました。
自分自身、わからないことがあればすぐに質問するように心がけました。 わからないことだらけだったので、うざいくらい聞いていたと思います笑。 1つ1つにちゃんと意味があり、それが今後の開発や運用に関わってくることが後から分かり、聞いておいて良かったと思っています。
入社してからずっとリモートワークだったので、画面共有をしながら作業しました。 自分や相手の画面をしっかり確認できる点が良かったと思います。 また、VSCodeのLive Share機能を使って、共同編集しながら行いました。 Live Share機能とても便利です。 共有画面には写っていないソースコードも確認でき、細かいスペルミスの修正や「こうも書ける」みたいなことなどを、チャットを介さずに直接編集できるので、作業効率が上がると思いました。
インフラの構成やアプリケーションの仕様などを、作業を進めながらドキュメントにまとめるようにしました。 自分なりに整理して言語化することで、頭の中が整理されて記憶に残りやすいと感じました。 また、作業に関わっていない人でもどんな構成・仕様になっているかを知ることができます。 自分自身も他の人が書いたドキュメントがとても参考になりました。 ECS化が終わってからもドキュメントに残すことを意識するようになりました。
アプリケーションの実行環境を移行するためには、アプリケーションのことだけでなくその周辺のことについても、様々なことを知る必要がありました。 例えばRailsやAngularのアーキテクチャの理解、リクエストがアプリケーションに届くまでの通信経路の把握、ログの保存方法、セキュリティの考慮などです。 ECS化を通じてこれらのことを学ぶことができ、とても貴重な経験になりました。
また、機能の変更を行う際にインフラの変更も必要になることが多くあります。 その時には何をするべきかを想定できるようになり、ECS化の経験を活かすことができていると思います。
新卒1年目でサービスの基盤であるインフラの構築を経験させてもらえたのはとても貴重だったと感じています。 実行環境を入れ替える機会はそう多くないことだと思うので。 会社全体として新卒や若手に役割をどんどん任せていく雰囲気があるため、チャレンジすることに躊躇はありませんでした。 また詳しい方たちのサポートも厚く、失敗したとしてもしっかりフォローしてくださる体制だったので、主体的に取り組むことができました。
入社してから取り組んだことの中で特に印象に残っているECS化について振り返りました。 新卒でもどんどんチャレンジさせてくれるClassiの皆さんのおかげでこの1年でとても成長したことを感じています。 この経験を活かして今後も主体的に取り組んでいこうと思います。
こんにちは、データAI部 Pythonエンジニアの工藤 ( id:irisuinwl ) です。
この度、Google Cloud の認定資格 Professional Cloud Architect に合格しました。
自分は去年の9月から Classi に join し、それまでオンプレミス中心で開発していたソフトウェアエンジニアでしたが、未経験から半年で資格を取得するに至りました。
本記事では、試験合格までに何を行い、何が効果的であったかを紹介したいと思います。
PCAに馴染みのない方もいらっしゃると思うので、簡単にどう言った資格なのか、どのような試験範囲が出るのかを紹介します。
PCAとは、GCP を用いてソリューションを構築するクラウドアーキテクトの能力を認定する試験となっております。
Professional Cloud Architect は、Google Cloud の技術を組織が活用するために必要なクラウド アーキテクチャと Google Cloud Platform に関する専門的な知識を活かして、ビジネス目標を推進するスケーラブルで高可用性を備えた堅牢かつ安全な動的ソリューションを設計、開発、管理するスキルを持ったアーキテクトです。 Professional Cloud Architect
試験内容としては、顧客の抱えるビジネス課題・技術課題に対して、GCPのサービスとして何を選択すれば良いのかを選択形式で問われる試験となっております。
例えば、模擬試験の問題を抜粋すると
A. Kubernetes Engine、Cloud Pub/Sub、Cloud SQLB. Cloud Dataflow、Cloud Storage、Cloud Pub/Sub、BigQueryC. Cloud SQL、Cloud Storage、Cloud Pub/Sub、Cloud DataflowD. Cloud Pub/Sub、Compute Engine、Cloud Storage、Cloud Dataprocと言った問題が出題されます。
出題される試験範囲は GCP のサービス全般と幅広い知識を求められます。例えば、以下のような区分となっております。
| 区分 | GCPの関連サービス |
|---|---|
| Computing | GCE, GAE, GKE, Cloud Run, ... |
| Network | VPC, Cloud Load Balancing, Interconnect, ... |
| Storage | GCS, Cloud SQL, Bigtable, Firestrore, BigQuery, ... |
| Operation | Logging, Trace, Monitoring, Profiler, ... |
| ML/Bigdata | Dataflow, Dataproc, AI Platform, ... |
自分は、業務で GCP を初めて利用したため、開発時に色々とスキル不足を感じたので、
Googleさん主催のトレーニングである Google Cloud Innovators Gym( G.I.G. ) を紹介いただき、参加することとしました。
G.I.G. では、講義セッション、 Coursera の選択コース、Professional Cloud Architect or Professional Data Engineerの認定資格取得支援(いずれかの合格もプログラム修了目標)などを用いた、 GCP のトレーニングとなっておりました。
また、G.I.G. 専用の Google Chat チャットルームでのサポート、もくもく会や懇親会など、交流する機会もあり、滞りなく学習を進めることができました。
特に、毎回の講義セッションでは、ハンズオンで扱うサービスの概観とハンズオンと深く GCP を理解できる内容であったことに加えて、受講者全体の学習状況をモニタリングされており、モチベーションにも繋がりました。
全体的に、リモートという状況下でも非常に学習効果が高く、 PCA という目標に向かった学習をよくモチベートするトレーニングで、教育業界に携わる身として非常に参考となりました。
結果として問題なくトレーニングプログラム修了することができました。
PCA 受験までに合格に寄与した学習内容を解説します。
ざっくり下記のように学びました。
詳細を以下では解説していきます。
GCP の概観は Coursera の講義で主に学びました。大体 2 ヶ月程度で完了しました。
受けたコースは以下です。
| コース名 | 概要 |
|---|---|
| Google Cloud Platform Fundamentals: Core Infrastructure | GCP の基本となるサービスを包括的に紹介するコース |
| Essential Cloud Infrastructure: Foundation | VPC と GCE の詳細を解説するコース |
| Essential Cloud Infrastructure: Core Services | Storage 系サービス, IAM, Cloud Operations の詳細を解説するコース |
| Elastic Cloud Infrastructure: Scaling and Automation | Interconnect, Cloud VPN, Cloud Load Balancing の仕様といった Network 系サービスの詳細と、 Deployment Manager 及び Terraform を利用したインフラ構築の自動化を解説したコース |
| Reliable Cloud Infrastructure: Design and Process | クラウドアーキテクチャを考える上での設計の考慮事項や要件定義を初めとして運用する上でのモニタリングまで、実践的な事項を解説するコース |
これらのコースは PCA の試験範囲を網羅しており、GCP の知識が 0 の自分としては非常に有益でした。
範囲の網羅性のみならず、演習問題が豊富であったことと、 Qwiklabs というハンズオンプラットフォームによる GCP を利用した演習もあったので、 GCP サービスを深く理解できるコースとなっておりました。
また、試験のみならず日常業務に有益な内容ばかりでした。
特に、Reliable Cloud Infrastructure: Design and Process はアーキテクトの思想やどのように GCP で構築したサービスの運用を行うかについて言及しており、実際に GCP を用いた開発でも学んだ知識を活用する場面が多くありました。
GCP の理解を深めるために、 Qwiklabs を用いた勉強会を1ヶ月間、 GCP のインフラに携わってる方々と実施しました。
Qwiklabs
Qwiklabs は、クラウドサービスのハンズオンプラットフォームです。
ハンズオンの受講を行うと演習用のプロジェクトが自動でクラウドサービス上に配備され、クラウドリソースから自動でハンズオンの進捗と合否を判定できるサービスとなっております。
Qwiklabs の 1ヶ月サブスクリプションを頂く機会があったので、それを利用し、勉強会で目標コースを定め、各自が学んだ内容を発表するということを行いました。
勉強会では、以下のクエスト(ハンズオンの集まり)を行いました。
- Build and Secure Networks in Google Cloud
- Perform Foundational Data, ML, and AI Tasks in Google Cloud
- Engineer Data in Google Cloud
1ヶ月という期間でしたので 1 週間に 1 クエスト、 1 日 1 つハンズオンを行っていたような気がします。
この中でも Build and Secure Networks in Google Cloud は GCP のネットワーク系サービスを用いたアーキテクチャについて取り扱っており、学びが多かったです。
VPN制限と Identity-Aware Procy (IAP) との使い分けも考えるきっかけとなり、社内サービスを IAP 対応する取り組みなどにも繋がりました。
勉強会については、軽率に興味のある分野の勉強会を開くことができ、学んだことを現状のインフラにフィードバックすることができる環境が Classi にあったことが非常に大きかったように思えます。
これが一番理解に繋がりました。実践が最強の学びな気がしてます。
入社してからおよそ以下のようなサービスをスキマ時間や自己啓発で構築してました。
それぞれ具体的なアーキテクチャを紹介します。
入社してすぐ作ったサービスです。自動生成した Sphinx ドキュメントをデプロイしたサービスとなっております。
以下のドキュメントを参考に作成しました。
Dockerでアプリケーションを作るのは1日で済みましたが、 VPC, Firewall, Cloud Load Balancing の設定などインフラ構築に1週間ほど手こずった記憶があります。
ある日モデル管理機運が高まって MLflow を構築したものです。
色々と熟れてきて Terraform とか使い始めたり、 App Engine が便利だと知って構築したものです。
Terraform書くのに結構困ったりで1ヶ月くらいかかりました。
また、権限まわりで面倒があったり、 GKE で構築したい気持ちが高まったので terraform destory しました。
割と最近作ったやつです。 streamlit による可視化サービスを作りました。
普通に Terraform で管理し、 GKE クラスタを作って誰でも爆速に GKE でプロトタイピングできるようにしようって思いで作りました。
アプリケーションは1日で作れましたが、インフラ構築に1週間ほどかかりました。
そんなこんなで入社して様々なサービスを構築してきましたが、やはり自発的に手を動かすことの学習効果は高いです。
また、GCP サービスを選定し設計する経験にも繋がるため、非常に有益になります。
自分が GCP 未経験から様々なサービスを作れたことは、 Classi が組織として
が起因していると考えております。
公式模擬試験と Udemy の Google Cloud Professional Cloud Architect Practice Test を利用しました。
模試を受けて理解の浅い部分を特定し再学習、再度模試を受ける形で対策を取りました。
特に手元で実践が難しかった Peering と Interconnect などは重点的に復習をしました。
試験受験前に公式模試は満点, Google Cloud Professional Cloud Architect Practice Test は6割解けるようになりました。
PCA合格のためにどのような学習を行い、何が寄与したかを振り返りました。
包括的な理解と実践と学習を支援する環境が大きな要因と感じました。
特に、貴重な機会をいただけた G.I.G. 事務局の方々に多大な感謝を述べさせていただきます。
資格合格がゴールではなく、ここで習得した知識を活かして Classi をより良いサービスにしていくことに尽力していきたいと思います。
フロントエンドエキスパートチームのlacolacoです。 この記事ではアプリケーション監視プラットフォームのSentryをClassiの中でどのように活用しているかを少し紹介します。Sentryの運用に悩んでいる方の参考になれば幸いです。
Classiでは大きく2つの目的でSentryを利用しています。ひとつはアプリケーションのエラーの監視（以後エラー監視と呼びます）、もうひとつはWebフロントエンドのパフォーマンスの監視（以後パフォーマンス監視と呼びます）です。
Sentryは多くのプログラミング言語用にSDKがあり、Classiでは主にJavaScriptとRubyのSDKを利用してフロントエンド・バックエンド両方のエラー監視を行っています。パフォーマンス監視は最近利用しはじめたのですが、バックエンドではもともとDatadogによる監視をしていたので、Sentryのパフォーマンス監視はフロントエンドだけで利用しています。
Classiはプロダクトを開発運用するためのいくつかのクロスファンクショナルチームが構成されており、その各チームでエラー監視を運用することを推進しています。
エラー監視はやるべきとわかっていても運用を継続するのが難しいものです。その大きな原因は導入初期のエラーのノイズ、いわゆるS/N比の低さです。エラー監視のためにずっとSentryの画面を見つめているわけにはいきません。エラーの発生を検知して迅速に対応するにはアラートの整備が欠かせませんが、導入初期はアラートが多すぎて通知されるのが日常化してしまいがちです。そのため、アラートの整備と同時にS/N比を向上していく取り組みも同時進行することが重要でした。
Classiでエラー監視の運用を定着させるために最初にやったのは運用ガイドの作成です。運用ガイドには次のことを書いています。
Sentryのアラートの通知先としてSlackを使うことと、その通知を見逃さないようにするためのポイントを書いています。
エラー監視のS/N比を改善していくために重要なのがトリアージの作業です。トリアージでは、その内容がどうであれ同じイシューが一定期間アラートされないようにします。具体的なトリアージの内訳は次の3つです。
判断を先送りする場合、チームで決めた一定期間（1-2週間ほど）そのイシューを無視します。Sentryには条件付き無視の機能があり、一定条件の間はアラートの対象外にできます。すぐには対応できませんが、アラートは止めつつそのエラーの存在をあとで思い出すことができます。
エラーの解決が見込めない、外的要因によるものであるなど、チームとして当面の間対応しないことを決めた場合は、通常の無視を選びます。直ちに対応することになった場合は、対応完了するまで（たとえば次スプリントまで）はアラートが出ないように条件付き無視を使うとノイズが減ります。
また、そもそもSentryに送信されるエラー自体を最適化していくためのガイドも作成しています。SDKの初期化設定によって対応しようがないエラーの収集を防ぐことができるため、S/N比を改善しながらSentryの課金クォータを節約することもできます。 この最適化については公式ドキュメントの Manage Your Event Stream, a Guide | Sentry Documentation をベースにして社内向けにチューニングしました。
各チームがエラー監視を運用していくことを推進する一方で、Classi全体でのエラーのトレンドも追跡しています。具体的には、毎週Sentryから送られてくるWeekly Reportの共有と、毎月の社内向けレポートの作成をしています。
毎週のWeekly Reportでは一週間でどのプロジェクトのエラーが多かったかがわかります。7日間の推移を見ながら、その推移が身に覚えがあるものかどうかを振り返り、もし把握していないエラーの増加があればチームに持ち帰って深堀りしてもらうようにしています。
毎月の社内向けレポートでは、SentryのDiscover機能を使って全プロジェクトの中での上位エラーを報告しています。Discoverはビジネスプラン以上になるとプロジェクトを跨いだ検索ができるようになってかなりパワーアップします。まるで別物のような使い心地です。
エラーへの対応でどのチームがうまく行っていて、どのチームが難航しているのかを俯瞰できることでフロントエンドエキスパートチームとしても支援の優先順位付けがしやすくなりました。
Sentryのフロントエンドパフォーマンス監視機能は Web Vitals の指標にも対応して非常に使いやすくなりました。
パフォーマンス監視は計測自体はできるようになったものの、これをどう活用するかについてはまだ道半ばであり、どのような運用が各チームの活動をサポートするものになるかを考えている最中です。たとえばリリースの前後でパフォーマンスの劣化がないかを確認することや、極端なパフォーマンス劣化をアラートすることなどをフロントエンド運用のガイドラインとしてまとめていきたいと考えています。
エラー監視の観点を中心に、ClassiでSentryをどのように運用しているかを紹介しました。運用は持続的に機能し続けることが求められますから、手間のかからず、なおかつ効果の高い運用方法を今後も模索していくつもりです。 もしSentryの運用に力を入れているチームがあればぜひもっと詳しい話をしながら意見交換してみたいので lacolaco 宛にDMなどいただけると嬉しいです。 それではまた！
© 2020 Classi Corp.
