新卒1年目でECS化に取り組んだことを振り返る

こんにちは。2020年4月にClassiに新卒入社し、エンジニアをやっている小川です。 私が入社した後に、各プロダクトの実行環境をEC2からECSにリプレイスしていく取り組みが始まりました。 AWSに触れた経験が全くありませんでしたが、私もこのECS化に取り組み、無事にリリースすることができました。 私がこの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年でとても成長したことを感じています。 この経験を活かして今後も主体的に取り組んでいこうと思います。

未経験から約半年でProfessional Cloud Architectを合格した振り返りをする

こんにちは、データAI部 Pythonエンジニアの工藤 ( id:irisuinwl ) です。

この度、Google Cloud の認定資格 Professional Cloud Architect に合格しました。
自分は去年の9月から Classi に join し、それまでオンプレミス中心で開発していたソフトウェアエンジニアでしたが、未経験から半年で資格を取得するに至りました。
本記事では、試験合格までに何を行い、何が効果的であったかを紹介したいと思います。

Professional Cloud Architect (PCA)の説明

PCAに馴染みのない方もいらっしゃると思うので、簡単にどう言った資格なのか、どのような試験範囲が出るのかを紹介します。

PCAとは、GCP を用いてソリューションを構築するクラウドアーキテクトの能力を認定する試験となっております。

Professional Cloud Architect は、Google Cloud の技術を組織が活用するために必要なクラウド アーキテクチャと Google Cloud Platform に関する専門的な知識を活かして、ビジネス目標を推進するスケーラブルで高可用性を備えた堅牢かつ安全な動的ソリューションを設計、開発、管理するスキルを持ったアーキテクトです。 Professional Cloud Architect

試験内容としては、顧客の抱えるビジネス課題・技術課題に対して、GCPのサービスとして何を選択すれば良いのかを選択形式で問われる試験となっております。
例えば、模擬試験の問題を抜粋すると

• Mountkirk Games は新作ゲーム用にリアルタイム分析プラットフォームを構築したいと考えています。新しいプラットフォームは同社の技術的要件を満たす必要があります。要件をすべて満たすことのできる Google テクノロジーの組み合わせはどれですか。
  • A. Kubernetes Engine、Cloud Pub/Sub、Cloud SQL
  • B. Cloud Dataflow、Cloud Storage、Cloud Pub/Sub、BigQuery
  • C. Cloud SQL、Cloud Storage、Cloud Pub/Sub、Cloud Dataflow
  • D. 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, ...

受けようと思ったきっかけ〜 G.I.G. への参加〜

自分は、業務で 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 受験までに合格に寄与した学習内容を解説します。

ざっくり下記のように学びました。

• Coursera で GCP 全体のサービスの仕様を理解
• Qwiklabs を用いた勉強会を開き、演習を通してサービスの理解の解像度をあげた
• 社内サービスを作って、サービスの細かい仕様やアーキテクチャパターンを実践した
• 試験の過去問を解いて、理解に不足している箇所を対策した。

詳細を以下では解説していきます。

Coursera

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 を用いた開発でも学んだ知識を活用する場面が多くありました。

Qwiklabs

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 にあったことが非常に大きかったように思えます。

GCPでサービスを作る

これが一番理解に繋がりました。実践が最強の学びな気がしてます。
入社してからおよそ以下のようなサービスをスキマ時間や自己啓発で構築してました。

• Cloud Armor, Cloud Load Balancing, GCE(Instance Group) を用いたドキュメントサービス
• App Engine, Cloud SQL, Cloud Storage を用いたモデル管理サービス
• GKEを用いたデータ可視化サービス

それぞれ具体的なアーキテクチャを紹介します。

Cloud Armor, Cloud Load Balancing, GCE(Instance Group) を用いたドキュメントサービス

入社してすぐ作ったサービスです。自動生成した Sphinx ドキュメントをデプロイしたサービスとなっております。
以下のドキュメントを参考に作成しました。

• https://cloud.google.com/load-balancing/docs/https/https-load-balancer-example?hl=ja
• https://cloud.google.com/iap/docs/load-balancer-howto?hl=ja

Dockerでアプリケーションを作るのは1日で済みましたが、 VPC, Firewall, Cloud Load Balancing の設定などインフラ構築に1週間ほど手こずった記憶があります。

App Engine, Cloud SQL, Cloud Storageを用いたモデル管理サービス

ある日モデル管理機運が高まって MLflow を構築したものです。
色々と熟れてきて Terraform とか使い始めたり、 App Engine が便利だと知って構築したものです。
Terraform書くのに結構困ったりで1ヶ月くらいかかりました。

また、権限まわりで面倒があったり、 GKE で構築したい気持ちが高まったので terraform destory しました。

GKEを用いたデータ可視化サービス

割と最近作ったやつです。 streamlit による可視化サービスを作りました。
普通に Terraform で管理し、 GKE クラスタを作って誰でも爆速に GKE でプロトタイピングできるようにしようって思いで作りました。
アプリケーションは1日で作れましたが、インフラ構築に1週間ほどかかりました。

---

そんなこんなで入社して様々なサービスを構築してきましたが、やはり自発的に手を動かすことの学習効果は高いです。
また、GCP サービスを選定し設計する経験にも繋がるため、非常に有益になります。

自分が GCP 未経験から様々なサービスを作れたことは、 Classi が組織として

• GCPの有識者に気軽に聞ける環境であったこと
• 監査ログのアラートや Security Command Center といった不味い操作を検知できる体制が整っていたこと
• IAMで欲しい権限を依頼して迅速に対応してもらえたこと

が起因していると考えております。

試験対策

公式模擬試験と Udemy の Google Cloud Professional Cloud Architect Practice Test を利用しました。

模試を受けて理解の浅い部分を特定し再学習、再度模試を受ける形で対策を取りました。
特に手元で実践が難しかった Peering と Interconnect などは重点的に復習をしました。
試験受験前に公式模試は満点, Google Cloud Professional Cloud Architect Practice Test は6割解けるようになりました。

まとめ

PCA合格のためにどのような学習を行い、何が寄与したかを振り返りました。
包括的な理解と実践と学習を支援する環境が大きな要因と感じました。
特に、貴重な機会をいただけた G.I.G. 事務局の方々に多大な感謝を述べさせていただきます。

資格合格がゴールではなく、ここで習得した知識を活かして Classi をより良いサービスにしていくことに尽力していきたいと思います。

Sentryを活用するためにやっていること

フロントエンドエキスパートチームのlacolacoです。 この記事ではアプリケーション監視プラットフォームのSentryをClassiの中でどのように活用しているかを少し紹介します。Sentryの運用に悩んでいる方の参考になれば幸いです。

Sentryの用途

Classiでは大きく2つの目的でSentryを利用しています。ひとつはアプリケーションのエラーの監視（以後エラー監視と呼びます）、もうひとつはWebフロントエンドのパフォーマンスの監視（以後パフォーマンス監視と呼びます）です。

Sentryは多くのプログラミング言語用にSDKがあり、Classiでは主にJavaScriptとRubyのSDKを利用してフロントエンド・バックエンド両方のエラー監視を行っています。パフォーマンス監視は最近利用しはじめたのですが、バックエンドではもともとDatadogによる監視をしていたので、Sentryのパフォーマンス監視はフロントエンドだけで利用しています。

エラー監視の運用

Classiはプロダクトを開発運用するためのいくつかのクロスファンクショナルチームが構成されており、その各チームでエラー監視を運用することを推進しています。

エラー監視はやるべきとわかっていても運用を継続するのが難しいものです。その大きな原因は導入初期のエラーのノイズ、いわゆるS/N比の低さです。エラー監視のためにずっとSentryの画面を見つめているわけにはいきません。エラーの発生を検知して迅速に対応するにはアラートの整備が欠かせませんが、導入初期はアラートが多すぎて通知されるのが日常化してしまいがちです。そのため、アラートの整備と同時にS/N比を向上していく取り組みも同時進行することが重要でした。

Classiでエラー監視の運用を定着させるために最初にやったのは運用ガイドの作成です。運用ガイドには次のことを書いています。

Slackでのアラート監視

Sentryのアラートの通知先としてSlackを使うことと、その通知を見逃さないようにするためのポイントを書いています。

• 自分のチーム専用のアラートチャンネルへ通知すること
• チャンネルの通知設定を「すべての新しいメッセージ」にしておくこと
• 通知が来たら必ず何らかの対応（以後トリアージと呼ぶ）をすること

トリアージ

エラー監視のS/N比を改善していくために重要なのがトリアージの作業です。トリアージでは、その内容がどうであれ同じイシューが一定期間アラートされないようにします。具体的なトリアージの内訳は次の3つです。

• 判断を先送りする
• 対応しないことを決める
• すぐ対応する

判断を先送りする場合、チームで決めた一定期間（1-2週間ほど）そのイシューを無視します。Sentryには条件付き無視の機能があり、一定条件の間はアラートの対象外にできます。すぐには対応できませんが、アラートは止めつつそのエラーの存在をあとで思い出すことができます。

1週間イシューを無視する機能

エラーの解決が見込めない、外的要因によるものであるなど、チームとして当面の間対応しないことを決めた場合は、通常の無視を選びます。直ちに対応することになった場合は、対応完了するまで（たとえば次スプリントまで）はアラートが出ないように条件付き無視を使うとノイズが減ります。

エラー収集の最適化

また、そもそもSentryに送信されるエラー自体を最適化していくためのガイドも作成しています。SDKの初期化設定によって対応しようがないエラーの収集を防ぐことができるため、S/N比を改善しながらSentryの課金クォータを節約することもできます。 この最適化については公式ドキュメントの Manage Your Event Stream, a Guide | Sentry Documentation をベースにして社内向けにチューニングしました。

チーム横断的なトレンドの追跡

各チームがエラー監視を運用していくことを推進する一方で、Classi全体でのエラーのトレンドも追跡しています。具体的には、毎週Sentryから送られてくるWeekly Reportの共有と、毎月の社内向けレポートの作成をしています。

月刊Sentry

毎週のWeekly Reportでは一週間でどのプロジェクトのエラーが多かったかがわかります。7日間の推移を見ながら、その推移が身に覚えがあるものかどうかを振り返り、もし把握していないエラーの増加があればチームに持ち帰って深堀りしてもらうようにしています。

毎週見ている2週分のレポート比較

毎月の社内向けレポートでは、SentryのDiscover機能を使って全プロジェクトの中での上位エラーを報告しています。Discoverはビジネスプラン以上になるとプロジェクトを跨いだ検索ができるようになってかなりパワーアップします。まるで別物のような使い心地です。

いつも使っているMost Impactful Issueクエリ

エラーへの対応でどのチームがうまく行っていて、どのチームが難航しているのかを俯瞰できることでフロントエンドエキスパートチームとしても支援の優先順位付けがしやすくなりました。

パフォーマンス監視

Sentryのフロントエンドパフォーマンス監視機能は Web Vitals の指標にも対応して非常に使いやすくなりました。

フロントエンドパフォーマンス監視

パフォーマンス監視は計測自体はできるようになったものの、これをどう活用するかについてはまだ道半ばであり、どのような運用が各チームの活動をサポートするものになるかを考えている最中です。たとえばリリースの前後でパフォーマンスの劣化がないかを確認することや、極端なパフォーマンス劣化をアラートすることなどをフロントエンド運用のガイドラインとしてまとめていきたいと考えています。

まとめ

エラー監視の観点を中心に、ClassiでSentryをどのように運用しているかを紹介しました。運用は持続的に機能し続けることが求められますから、手間のかからず、なおかつ効果の高い運用方法を今後も模索していくつもりです。 もしSentryの運用に力を入れているチームがあればぜひもっと詳しい話をしながら意見交換してみたいので lacolaco 宛にDMなどいただけると嬉しいです。 それではまた！

Classiで行われている部活動の紹介 〜CTF caféはじめました〜

こんにちは、Classi株式会社 プロダクト開発部所属のid:kiryuanzu です！ 2020年4月から新卒のエンジニアとして入社し、現在は学習記録でサーバーサイドエンジニアの業務を担当しています。
今回の記事では、Classiの中の部活動の一つとして運用されている「CTF café 」、そしてその部活の課外活動の一環として参加したHardening 2020のイベントの体験記を紹介します。

CTF café はじめました！

ご存知かもしれませんが、CTFとは「Capture The Flag(キャプチャー・ザ・フラッグ)」の略であり、フラグ(Flag)と呼ばれる隠された答えをセキュリティの知恵を駆使して探し出す競技のことです。競技の中身は、クイズ形式のものや実際にサーバを攻撃・防衛する形式といったものがあり多岐にわたります。

Classiの中にはセキュリティやCTFに興味を持つ方が多くいます。
過去のClassiのWantedlyの記事では、活動に関わっている野溝が女性限定のCTF大会「4-Girls CTF 2019」というイベントに参加した際の体験記を書いています。 www.wantedly.com

筆者自身も、入社前にこの記事を読んで「CTF、やったことないけど楽しそうだな〜、会社の中に詳しい人がいるのならちょっと触ってみようかな……!」と興味が湧き始めました。
そして、Twitterや入社後に作った分報チャンネルでCTF興味がある旨を呟いた後日のことです。「社内の有志を集めて一緒にCTFの問題を解いてみませんか！」と誘われ、CTFを始めるようになりました。

そのような流れを経て、社内のSlackに「#ctf」というチャンネルを立て毎週火曜のお昼にSlack callに集まる部活が誕生しました！その部活をCTF caféと呼んでいます。

部活動メンバーとの和気藹々とした様子を一枚におさめました

CTF caféの主な活動内容はオープンに公開されているCTFの問題(ksnctf, cpawctf, picoCTFなど)を協力して解き合ったり、定期的に開催されるセキュリティ関連のイベントに参加するといったものです。
ずっとガチガチにやるといったものではなく、問題を解きつつ近況を交えた雑談を挟んだり、古のインターネット話に花を咲かせることも時折あります。

筆者自身、完全初心者ということもあり最初はどう解くか分からない問題も多かったですが、CTF経験者のメンバーからのアドバイスによって、次第に頻繁に出てくる暗号の解き方を理解したり、「こういう時はstringsコマンドでバイナリファイルの中身を見たらいいんだ！」とすぐに気付くようになりました。問題で用意されるパケットキャプチャを覗きたい時はWireSharkを使うのも慣れてきました。
まだまだ初心者ではありますが、「この時にはこのツール/コマンドを使おう」と頭の中で繋がるようになってきました。
また、OSINT(簡単に説明するとネットに公開された情報だけで目的の情報を特定する形式の問題です)をやるようになってからは迂闊に店名や特徴的な建物が写り込んだ地理写真をあげるのはできるだけ気をつけようと思うようになりました。

活動記録に関しては、メンバーの一人がesaの中でセンスあるタイトル付きで毎回まとめて社内に共有しています。

「なれる! SE」風と社内で評判です

Hardening 2020 に行ってみた！

筆者がCTF caféに参加するようになって1ヶ月ほど経ったある日、部活メンバーから「Hardening 2020というイベントに参加してみませんか」と声をかけられました。

Hardeningとは、簡単に要約すると外部からの攻撃を防御しつつ、運用を任されたサービスの売り上げを最大化する競技のことです。このイベント自体はCTFに分類されるものではありませんが、CTF同様にセキュリティの知識を駆使して競技に挑むといった点では同様であると言えます。 公式サイトの説明では以下のように書かれています。

Hardening競技会は、基本的にチームに託されたウェブサイト(例えばEコマースサイト)を、ビジネス目的を踏まえ、降りかかるあらゆる障害や攻撃に対して、考えうる手だてを尽くしてセキュリティ対応を実施しつつ、ビジネス成果が最大化するよう調整する力を競うものです。

その説明だけを聞いた時点では、「どうやって守っていけばいいの……!そもそもどんな攻撃が飛んでくるんだ……!?」とまだまだ未知の領域でしたが、チームを組むことになった方々や過去にHardeningに参加したClassiの社内メンバーによって講習会が開催され、どのような準備や戦略立てが必要であるかを知ることができました。
準備期間は1ヶ月で、応募者の中から10人構成のチームを組んで準備を進め、本番当日は上記で説明したように出されたお題に応じてサービスを運用し、攻撃から守り抜くことになります。
ちなみに、大会応募時には個人応募とチーム応募(3人まで)を選ぶことができ筆者はチーム応募で部活メンバーの2人と一緒に参加しました。 他の7人のメンバーの方は、Classiと似たようなWeb関係の出身の方もいれば生活インフラのシステムや病院のシステムを運用されている方、学生とエンジニアの二足のわらじをやっている方など多種多様なメンバーで構成されており、普段交流できないような方々と協力し合いながら学ぶことができ、セキュリティ関係のコミュニティの空気感についても知ることができました。
チーム名はISUCONジェネレーターを使って「おにぎりまみれ」という名前に決まりました。アイスブレイクとして好きなおにぎりの具を言い合ったり、チームメンバーの一人かつClassi社員の野溝がロゴを作成しました。

結果は……?

チームの方々と一緒に大会本番に向けて準備を続け、ついに当日を迎えました。 本番中のインシデントでは、ショップのトップページが何者かに改ざんされ当時流行していたドラマの画像が貼られたindex.htmlに変えられてしまったり……(チームメンバーの1人かつClassi社員の高田が30分で直して事なきを得ました)。
運用の手続きに必要なWEBページがDNSエラーで到達不能になり、Discordで運営の方に購入サイトのIPアドレスを教えてもらい危機を回避するなどがありました。
技術的なイベント以外にも、発生したインシデントについて親会社の役員に説明を求められたという設定で、怖い役員に扮した運営メンバーの方から呼び出されるといったこともありました。どうやらこの公開呼び出しイベントは毎年お馴染みのようです。

そして結果は……！ 筆者も含めたClassi社員の3名が所属するチーム「おにぎりまみれ」が総合優勝しました！！！！！！

まさかの初参加でこのような素敵な体験をさせていただくことができ、本当に感謝しています。後日行われた振り返りの場でもこのような結果が残せたのは、チームワーク重視で動き続けたことがよかったのではないかとチーム内で意見が一致しました。

具体的には、チーム内のメンバーの誰かが困っている時はすぐにチャットで反応したり声かけを行うなど、リアクションを徹底して行い、誰かの発言が虚空に消えそうな雰囲気を感じた場合はすぐに反応をして不安を取り除けるよう動くようにしたことで、お互いの役割を認識し合いながら作業内容を把握して進めていくことができたのではないかと思います。

まだまだ「旅」は続く

CTF caféがきっかけとなりこのような大変面白い体験ができました。しかし、これで終わらず部活メンバーと共にセキュリティに関する知見を深め合いながら問題を解き進めたり、他の面白そうなセキュリティ関連の大会に参加して経験を積んでいきたいです！

Classiでは、このような面白い課外活動が活発に行われております。 この記事を読んで「自分もこのようなコミュニティに関わってみたい！」と感じた方の応募をいつでもお待ちしています！

リモートでPeople+AI Guidebookの輪読会をやった話

こんにちは。データAI部部長の伊藤(@tetsuroito)です。

Classiの組織はマトリクス型の組織を採用しており、縦では職能別の部門、横では機能チームごとに分けて、日々の業務にあたっています。

今回の記事では、データAI部とUXデザイン部が共同で取り組んだ輪読会の内容をお伝えします。輪読したものはGoogleが2019年に公開したPeople+AI Guidebookの日本語版です。

輪読会開催のきっかけ

日々の業務では横軸のチームで動くことが多く、部門間のやり取りもチーム内でやりとりすることが多くありました。しかし、縦の部門でそれぞれの職務における能力開発が担われており、UXデザイン部ではUIやUXデザインに関する専門的な能力開発が、データAI部ではデータサイエンスや機械学習などの専門的な能力開発がそれぞれ行われていました。

しかし、データサイエンスや機械学習などは取得されたデータから新たな価値を創出していく活動のため、システムやプロダクトにおけるユーザー体験がデータを生み出すメカニズムそのものに強く影響を与えます。

そのため、2つの部門で同じような課題意識を共有できる取り組みができないかと思っていました。そんな課題意識をUXデザイン部の副部長の松本さんに相談したところ、まずは輪読会をやってみようということになりました。

輪読会の開催概要

リモート環境下における輪読会なので、どのような体裁で開催するかは少し工夫をしました。

項目	方法
開催頻度	毎週金曜日11:00-12:00
読む物	People+AI Guidebook(翻訳版)
各回の概要	1回目：はじめに 2回目：ユーザーニーズ+成功の定義 3回目：データ収集＋評価 4回目：メンタルモデル 5回目：説明＋信頼感 6回目：フィードバック+コントロール 7回目：エラー +上手な失敗 8回目：ふりかえり
輪読会構成	前半30分 担当箇所を読みながら付箋に書き出す 後半30分 付箋を眺めながら気になった観点を議論する 締めにグラフィックレコーディングを確認する
使うツール	Miro

輪読会の開催方式は色々とありますが、今回は専門領域の異なるメンバーが参加しているため、同じ認識を持ちながらそれぞれの立場での読み解きの視点や感想などをシェアすることを重視しました。

そこで、特に担当箇所などは割り振らず、毎週決まった章をみんなで読んで、感想を出し合う形式にしました。各回の分量も適切なサイズに切り分け、事前に予習してこなくても大丈夫なように、前半30分を読む時間にあて、その中で気になる観点を書き出し、後半にそれを話し合うことで気づきを得られるようにしました。

今回、UXデザイン部のメンバーが参加してくれたことで、輪読会での議論の様子をグラフィックレコーディングにしてもらいました。最後にそれを眺めて振り返ることで、理解を促進するような構成にしました。

輪読会の様子

はじめにを読んで、輪読会に期待することを書いた初回

データ収集+評価の回

エラー+上手な失敗の回

このようにはじめの30分で章を読みながら気になった箇所を個々で付箋に書き出し、他の人がどのような観点が気になっているのかをみることで、また新たな発見や視点を得ることができました。その様子をグラフィックレコーディングで描いたのが右手に描かれている内容です。

ふりかえり

すべての章を読み終えた後に、輪読会自体のふりかえりも行いました。

People+AI Guidebookには章によってデータ系に近い章とUXに近い章がそれぞれありましたが、みんなが共通して印象だった箇所として、「メンタルモデル」や「期待値調整」、「AIの目的は自動化か拡張」などの観点があげられました。

また、最終的にAIシステムのためのUXデザインについて学んでいたはずが、一般的なシステム開発にも活かせる内容も多く、そうした気づきを得られてよかったことや、自身の関わっているプロジェクトにも活かせそうだという意見も多く書かれていました。

今回、職能を超えた活動をする上で、People+AI Guidebookが非常に取り組みやすいコンテンツだったと思います。こうした活動の媒介となるコンテンツがあるということは非常にありがたいなと感じました。

まだまだ質的な部分と量的な部分のコラボレーション事例はそれほど多くはありませんが、こうした活動をきっかけに良い取り組みができるように頑張っていきます。

AWS ECS監視のオオカミ少年化を防ぐために考えたちょっとしたこと

こんにちは。エンジニアの遠藤です。

Classiでは、Datadogを使ってシステムの各種メトリクスをモニタリングし、異常があればSlackにアラート通知を飛ばすように設定しています。

今回は、AWSのECSのタスク数に関するアラート通知の設定を変更する機会があり、そのとき何を考え、どう変更したのかという日々の運用の様子を紹介したいと思います。

もともとの設定

あらゆるECSのサービス（以後、サービス）のタスク数について、

aws.ecs.service.desired - aws.ecs.service.running

が5以上になればアラート通知を飛ばすように設定していました。

もともとのDatadogの設定

理由としては、例えばサービスAについては desired task が 10 で設定されていて、サービスBについては desired task が 20 で設定されていたとしても、上記の設定であれば問題なく異常（予期せぬ稼働タスク数の減少）を検知できて、汎用性があるからです。

問題

しかし、あるサービスでタスクのスケジュールベースのオートスケールを設定したとき、上記の設定では問題が発生するようになりました。

そのサービスのタスクは、17:00になると10 -> 30 にスケールアウトし、 18:00になると 30 -> 10 にスケールインします。

先のタスク数のモニタリング設定では、17:00に必ず aws.ecs.service.desired - aws.ecs.service.running = 20 となるので、毎日 17:00 にアラート通知が飛ぶようになってしまいました。

これだとアラート通知がオオカミ少年化しているので、なにか対策をしたいところです。

対策

一案として、上記のサービスのみ通知先のSlackチャンネルを変更し、もともと通知を飛ばしていたアラート用のチャンネルからノイズを取り除きつつ、別チャンネルで検知するという対応が考えられました。

ただ、温度感の高いアラート用チャンネルに通知されなくなるので、本当に予期せずタスク数が減少していることを検知する機会を逃すかもしれず、不安です。

何を監視・検知したいのかを改めて考える

そこで「何を監視したいんだっけ？」に立ち返って考えてみると、結局、検知したいのは予期せぬタスク数の減少です。

シンプルに、そのタスク数の減少をモニタリングすればいいのでは？という考えに至りました。 結果的に、以下のように設定しました。

変更後のDatadogの設定

通常稼働しているタスク数は10であるサービスなので aws.ecs.service.running が8以下になったとき、アラート通知を飛ばすように設定しました。
（ちなみにこのサービスについては Blue/Green デプロイをしているので、デプロイ時に稼働中のタスク数が瞬間的に10を下回ることはありません）

このモニタリングの設定は汎用的ではありませんし、タスク数の定義を変更するたびにアラートの閾値を変更する必要があるという若干のトレードオフはありますが、目的は十分に達成できるので採用しました。

まとめ

Datadogのモニタリングの小さな設定変更ですが、タスク数の予期せぬ減少は致命的な障害が起きている可能性が高いので、注意深くメンテナンスしていく必要があります。

Classiでは、今回のような運用の改善をポジティブに捉える文化が根付いていて、日々継続的な改善に取り組んでいます。

ほんの一例ですが、事例としての紹介でした。

これからもこういった日々のメンテナンスを怠らず、積極的に改善していけたらと思います。

GitHubのテンプレートリポジトリを継続的に運用する

フロントエンドエキスパートチームのlacolacoです。今回はClassiの中で運用しているGitHubのテンプレートリポジトリについて、その運用方法を紹介します。これが最善である自信はないですが、一例として誰かの参考になれば幸いです！

テンプレートリポジトリ機能とは？

docs.github.com

テンプレートリポジトリは通常のリポジトリと同様にcloneやpull、pushなどできるGitリポジトリとして機能します。テンプレートリポジトリが通常のリポジトリと違うのは、新しいリポジトリを「テンプレートから作成」できる点です。 テンプレートからリポジトリを作成することは、リポジトリをフォークすることに似ていますが、以下の点で異なります。（ドキュメントより引用）

• 新しいフォークは、親リポジトリのコミット履歴すべてを含んでいますが、テンプレートから作成されたリポジトリには、最初は 1 つのコミットしかありません。
• フォークへのコミットはコントリビューショングラフに表示されませんが、テンプレートから作成されたリポジトリへのコミットはコントリビューショングラフに表示されます。
• フォークは、既存のプロジェクトにコードをコントリビュートするための一時的な方法となります。テンプレートからリポジトリを作成することは、新しいプロジェクトを素早く始める方法です。

Classiにおけるテンプレートリポジトリ

テンプレートリポジトリは似たプロジェクトを何度も作成するときの雛形を管理する方法としてとても適しています。その一例として、Classiのフロントエンドエキスパートチームでは、AngularJSからAngularへの段階的移行を支援するテンプレートリポジトリを作成しています。

Classiのコードベースは機能やデプロイ単位に基づいていくつかのリポジトリに分割されています。そのため、ひとつの大きな移行ではなく、いくつもの段階的移行が並行して進行することになります。

AngularJSからAngularへの段階的移行では、AngularコンポーネントをCustom Elementsに変換して、それをAngularJSを利用している旧実装のHTML中に埋め込んで置き換えていくという手法を取っています。Angularコンポーネントは単にCustom Elementsにするためだけのソースコードではなく、移行の最終段階ではそのままAngularアプリケーションとして根本から置き換え可能である状態を作っていきます。

つまり、ひとつのプロジェクトの中でAngularのソースコードを通常のアプリケーションとしてデプロイできるビルド設定と、Custom Elementsのパッケージとしてデプロイできるビルド設定の共存が必要になります。毎回それぞれのプロジェクトにリポジトリの作り方をレクチャーしていくのは骨が折れますし、設定を改善したときにそれを全体に伝えるのも共通の土台がないため難しいです。

テンプレートリポジトリを運用することで、どのプロジェクトも同じスタートラインになっており、設定の改善も同じ変更を適用できることをある程度保証できるようになりました。また、実際にプロジェクトを進めていく中での発見をテンプレート側へ還元するループも生まれやすくなりました。

継続的な運用のための変更履歴

このようなテンプレート的存在は時間の経過につれメンテナンスがされなくなったり、テンプレートから新しく作成した時点からいままでの差分がわからないということになりがちです。この問題を緩和するために、テンプレートリポジトリの変更履歴を文書化しています。

具体的には、テンプレートリポジトリ内ではConventional Commits のルールに従うことで、 standard-version CLIを使ってCHANGELOG.md を自動生成できるようにしています。キリのいいタイミングでテンプレートのバージョンを更新することで、「テンプレートを更新したので各チームで変更点の追従お願いします」というコミュニケーションが容易になります。 コミットログだけではノイズが多いため、Conventional Commitsによってfeatとfixの差分がまとめられることで本当に重要な変更だけを伝えやすくなっています。

CHANGELOGの例

今後の課題

現状どうしても人力に頼っているのは、テンプレートのバージョンアップを派生先のリポジトリ達に伝えに行くところです。ここは何かしらの方法を使って自動化できないかと考えているところです。たとえばGitHub APIでそのテンプレートから作られたリポジトリを走査してIssueを作成にしにいくなどできるかもしれません。 また、変更の追従自体もテンプレート側のDiffをなぞって真似することになるため、マイグレーションパッチを適用するだけで済むようになれば楽になるかもしれないと考えていますが、テンプレートからの作成後に加えられた変更でパッチの互換性がなくなってしまうケースも考えると一筋縄ではいかないですね。

とはいえ、変更履歴とバージョニングを自動化するだけでもテンプレートリポジトリの運用がやりやすくなりました。読者の中でテンプレートリポジトリを運用している方の参考になれば幸いです。