はじめに 立ち話から株価通知くん、爆誕 技術投資とソリューションチーム 越境とソリューションチーム 具体事例 株価通知くん メンション集約くん ユーザー管理システムの権限移譲 今後について はじめに 技術部インフラGの鈴木です。先日金沢競馬で最終レースで全てを取り返す体験をしたところ、久しぶりに生きていると感じました。 ところで、今回は以前こちらの勉強会にて話した内容をもとに、今年から始まった「会社に紐づくエンジニアリング」を行うソリューションチームの活動についてお話しします。 勉強会の時に使用したスライドは以下となります。 speakerdeck.com 立ち話から株価通知くん、爆誕 リブセンスはフルリモートなのでSlack上で積極的に話す文化であるWOLを実践しても、出社時と比べてどうしても雑談が少なくなりがちです。他部署等、自分と積極的に関わりのない人たちとは特にそれを感じます。 そ

はじめに 技術構成（before）と課題 技術構成（after）と選定の理由 改善したこと パフォーマンスの向上 デリバリー速度の向上 セキュリティ面でのリスク低下 大変だったこと 記事のマークダウン変換 段落分けと改行の区別 字下げ 書式の追加 Lintが必要になった 記事ごとのOGP画像周りの実装 URL変更に伴うリダイレクト設定 標準の検索機能がない おわりに はじめに 技術部の @mom0tomo , @etsxxx です。 技術部では、事業部横断的な仕事としてコーポレートサイトの運用も行っています。このたびWordPress on EC2で運用されてきた弊社のWebメディア（Q by Livesense）を、Hugo on Clouflare Pagesに移行しました。 q.livesense.co.jp 弊社のWordPress運用はやや特殊で、エンジニアがサーバーにSSHして

概要 背景 移行 移行前の構成 (MySQL, PHPバッチ) 移行後の構成 (DynamoDB, Kinesis) 移行の段取り 詳細 ストリーミング処理 APIサーバー APIクライアント 移行を終えて 最後に 概要 技術部インフラグループの春日です。 2024年上期現在、弊社ではオンプレデータセンターで稼動しているサーバーのクラウド移行を進めており、 2024年1Qの時点で大半はAWSへの移行が完了しています。 本記事では社内で古くから運用し続けているメール配信サーバーのバウンスマネジメントに使用するアドレス帳データをクラウド移行した件について振り返ります。 メール配信サーバー自体のクラウド移行に関しては本記事では触れません。 以降の章ではメール配信サーバーを自前で運用している背景やクラウド移行前後での構成比較、および移行後のシステム詳細について触れていきます。 なお記事内ではEメー

こんにちは。転職ドラフトでエンジニアをしている verdy_266 です。 突然ですが、あなたはLTの覇者になりたいと思ったことはありませんか？ 僕はあります。 内容のわかりやすさはもちろんのこと、喋りも上手で百発百中で場を沸かせることのできる人、これを僕は「LTの覇者」と呼んでいます。 LTの覇者は、発表で強い印象を残すことができ、自分の伝えたいことを聴衆に伝えることができるので、懇親会でも話が尽きません。発表内容について新たな知見を得ることができるので、勉強会で持ち帰れることも他の人に比べると多いでしょう。こんな人に、なりたいと思いませんか？ 今回は、ある本を読んで僕がLTの覇者を目指している話をします。 LTは印象が9割 「よいLT」とはなんでしょうか。色々な要素があると思いますが、今回は「どれだけ強い印象を与えられたか」という点にフォーカスしたいと思います。 せいぜい5-10分程度

背景 作ったもの リダイレクトツール(redirector)の作成 redirectorの開発言語選定 設定ファイルについて redirector開発で工夫した点 リダイレクトサービス動作環境の構築 リリース後の反応 終わりに 技術部ソリューションチームの @etsxxx , @mom0tomo です。 ソリューションチームは全社の課題をエンジニアリングによって解決することを目的に2024年に発足したチームです。現在はインフラグループと情報システムグループのメンバーによる兼務で運営しています。 今回はソリューションチームとしての初リリースとなったOSSのURLリダイレクトツール(以下、redirector)とその導入後の効果について紹介します。 github.com 背景 作ったもの リダイレクトツール(redirector)の作成 redirectorの開発言語選定 設定ファイルについて

こんにちは、かたいなかです。 2024年2月に長年の悲願だったマッハバイトのメインDBのAuroraへの移行を完遂しました！！！ この記事では、どのようにマッハバイトのAurora移行を進めていったかを記事として残します。 なお、この記事の中では結構レガシーな部分の対応に苦しんだところも出てくるのですが、DB移行が終わったあとで、弊社内でこのレベルのレガシー対応を行う必要があることはほぼないと考えているので、リブセンスに興味を持っている方も安心して読んでいただければと思います。 やったこと プロジェクトの流れ テックリードから聞く初耳の単語: 『Mroonga』 状況をざっくりと調査 このコード使われてるの？使われてないの？ DMSの検証本格化 移行準備期 ついに、本番移行 Auroraに移行してよかったこと パフォーマンス改善 Performance Insightsが便利！！！ DB移

はじめに 技術部インフラグループの春日です。 2024年現在、弊社が運営している マッハバイト は一部を除いてオンプレからクラウドへの移行が完了しました。 本記事では移行対象の1つであった Apache Solr に関する総括をします。 今回のプロジェクトでは移行自体を最優先とするため、スコープを以下に定めていました。 Apache Solrから他の検索エンジンへは乗り換えない アプリケーション側の改修は向き先の変更だけに留める Apache Solr自体のバージョンUP対応はしない 運用負荷を軽減できる形の構成変更を加える 移行スピードと移行後の運用コストとの天秤 新たに運用しないといけなくなるコンポーネントはなるべく増やさない モニタリングや監視の精度はなるべく落とさない 上記を踏まえ、以降の節ではApache Solrのサービス内利用箇所の紹介から始め、 インフラ構成・デプロイ・モニ

はじめに イメージ 実行 フローチャート しんどいポイント VS インタラクティブな操作 APIからstdoutが取れるが、途中で切れる sudoでコマンド叩こうとするとttyがなくてエラーになったが… 実装 Issueへのコメントを実行トリガーにする 実行トリガーのコメントにリアクションでいいねをつける Issue本文からコマンドと対象インスタンスを取得する サンプルIssue本文 コマンドの取得 インスタンスIDの取得 OIDCでAWSへの操作権限を安全に取得する 【参考】IAMロールの権限 OIDCで権限の取得 コマンドの実行 実行結果の取得 実行結果をissueにコメントで貼り付ける debugに役にたつ結果をissueにコメントで貼り付ける 作ってみて はじめに インフラGの鈴木です。先日高知競馬で負けた後、朝5時に起き、エクストリーム出勤してこの記事を書いています。 ところで、

これは SRE Advent Calendar 2023 DAY 22 の記事です。 はじめに 自分しかわからないPR なぜ読まれなかったのか 実際のPR 設計という共通認識の重要性 経緯を残すと++ ちいさくてかわいいPR わかりやすいPRのTips 直したPR 終わりに はじめに リブセンスでインフラグループに所属している鈴木です。競馬に行きすぎて、行ったことない地方競馬場が水沢と高知だけ1になりました。今後は釜山か済州2を考えています。 ところで、クラウド移行を複数経験したことで感じたことを共有しようと思います。なお本記事は第2回ゆるSRE勉強会の登壇資料をもとに作っています。 自分しかわからないPR オンプレのVMで動いていた社内認証基盤をECS Fargateに移行する案件がありました。構成は下記となります。 nginxのリバースプロクシ oauth2-proxyという様々なID

はじめに インフラGの鈴木です。土日はばんえい競馬を生で見て感動しましたが、馬券は全部外しました。 ばんえい競馬は馬が動くのに合わせて横を追走して鑑賞できます、本当に迫力がすごいです。競馬場グルメもおいしいですし、おすすめです。 ところで、先日勉強会で初めて登壇しました。今回はその登壇の様子を紹介します。 なぜ登壇したのか シンプルに目立ちたがり屋なので、昔から登壇したいと思っていました。 他には、過去に勉強会に登壇なしで参加した時、懇談会で他の人に話しかけるのがコミュニケーション力が必要で難しかったからです。なので登壇者の場合、話しかけるのも話しかけられるのもやりやすそうで、楽しそうだなと思ったのがあります。 登壇して得たこと まず自信がつきます。その次に言いたいことを明確化し、わかりやすく伝えるプロセスが鍛えられます。 LTは大体5分です。やってみるとわかりますが、5分で伝えられること

はじめに 転職ドラフトでの技術名の使われ方 なぜ技術名の表記がゆれるのか 頭字語の多さ 読み方の難しさ たくさんあるクラウド 統合方針 ベンダーの公式の表記に従う オープンソースも公式ウェブサイトの表記を尊重する その他細かい大文字・小文字の違いや単語間の空白、複数形などについて、わかる限り公式に合わせる 誤字・タイポは修正（でも本当に間違ってるの？） 結論 はじめに 少し前のことになりますが、転職ドラフトではサービス内で使われる技術名の表記を統一しました。 リリースノートの8/29「技術名の表記ゆれを統合しました」にある通り、サービス内でバラツキがあった、プログラミング言語、各種ミドルウェア、OSS、クラウドサービスなどの、いわゆる技術名（6000個ほどもあった）を、社内のエンジニアで手分けして調査し、適切と思われるものに変換するためのデータをゴリゴリ作りました。 この記事では、近年大き

はじめに レビューに対する考え方 参考資料 Google Engineering Practices Documentation 30分でわかるFour Keysの基礎と重要性 DevOps 測定: 仕掛り制限 考え方 レビュイー レビュワー おわりに はじめに テクノロジカルマーケティング部データプラットフォームグループでグループリーダーをしている富士谷です。普段は、データ収集基盤 Livesense Analytics とデータ活用基盤 Livesense Brain の開発を行い、マネジメントもしています。 さて、今回は、データプラットフォームグループの「レビューに対する考え方」をご紹介したいと思います。なお、あらかじめ、お断りしておきたいのですが、リブセンスの開発チームすべてが同様の考え方とは限らず、あくまで、あるチームの一例であることをご了承ください。 本題に入る前に少し背景を説

リブセンスインフラエンジニアの中野(etsxxx)です。VPoEという立場でもあります。 最近はルビコン出張が忙しかったのですが、やっと落ち着いたので、徐々にスターフィールドの旅に出ています。相変わらずガラクタばかり集めて売り捌く行商状態です。 はじめに リブセンスでは多くの事業部で、AWSのリソースをTerraformでコード管理しています。 マッハバイトのAWS移行が進むにつれてECS Scheduled TaskやAWS Backupなどの利用が増え、TerraformにはAWS Cron式によるスケジュールの記載が増えてきました。 TerraformにおけるAWS Cron式の記述例 schedule_expression: cron(55 * ? * 1-2,4-5 *) ところがこのAWS Cron式。ただでさえCron式は読み書きしにくい代物なのに、AWSの書式(AWS Cr

はじめに Brakemanとは 導入方針 導入方法 終わりに はじめに 普段アルバイト事業部で主にバックエンドの開発をしている@ayumu838です。 最近はStaubのホーロー鍋を買って煮込み料理をよく作って食べています。 食欲の秋なので日々のカロリー摂取量は増加の一途を辿っているのが少し心配です。 ところで皆さんは、自身のRailsプロジェクトに対してセキュリティチェックを行っていますか？ この記事では、GitHub Actionsを使ってRailsプロジェクトに対してBrakemanを導入して、セキュリティチェックを行った時の話です。 Brakemanとは ソースコードに対してSQLインジェクションやXSSなどの脆弱性がないかを解析してくれるGemです。 人間が目視で確認していても抜け漏れがあったり、新たに報告された脆弱性に気付きにくかったりするので、こういった自動で検知してくれるツ

はじめに インフラGの鈴木です。最近海外に行きやすくなったのと、パスポートの更新をしたことから、韓国の清道闘牛と釜山競馬のことしか考えてません。 ところで、リブセンスに入社して半年になりました。同時に社会人歴10年の節目なので、棚卸しがてら振り返ってみたところ、色々考えるきっかけになったので、共有してみます。 私の経歴 サマリ 大学を無内定卒業 半年に一回バイト変えて、最終的に日雇いみたいなのを1年半くらい 未経験でソフトハウスに半年 システムオペレータを3年 SIerでインフラエンジニアを3年 外資のコンサルティングファームでSEを4ヶ月ほど リブセンスに入社して半年 説明 大学卒業後は、やりたいことがなかったので、就職せずフリーターをしていました。 その後未経験でソフトハウスに入っていわゆるSES的な仕事をしていましたが、とんでもないことに1ヶ月くらい自分のPCがない現場でした。色々お

移行の背景 どんなアプリケーションを移行したのか 移行後の構成 移行で直面した課題 認証・認可機構が複雑になっている 処理に時間がかかるエンドポイントがあり、ALBのIdle Timeoutのデフォルトでは足りなかった 非同期処理用のdelayed_jobのワーカーがバッチサーバー上で起動している AWS移行による副次的な効果 おわりに 移行の背景 インフラストラクチャーグループの @mom0tomo です。ここ2年ほど、マッハバイトのクラウド移行に取り組んでいます。 リブセンスでは長年データセンターを借りてオンプレミスでサーバーを運用してきました。ただ最近のクラウド化の流れを受け、いくつかのサービス（転職会議や転職ドラフトなど）はオンプレからクラウドへ移行し、また新規事業であるknewやbatonnなどは、初めからクラウドサービスを利用しています。 しかし、創業期からの歴史のあるマッハバ

こんにちは、かたいなかです。 マッハバイトではシステムのオンプレからAWSへの移行を絶賛爆速で進めています。 そのなかでDB移行の下準備としてRidgepoleを導入することにしました。 今回はそのRidgepoleの導入について記事にまとめます。 Ridgepoleとは なぜRidgepoleを導入したのか AWS移行時にテーブル構造を変更する必要がある箇所がある： Ridgepoleで比較を容易に DMSのためにインデックスや外部キーをあとから別々に適用できる必要がある：Ridgepoleで不要な箇所をコメントアウトする GitHub ActionsでRidgepoleを動かす Pull Requestにスキーマの差分をコメント マージ/タグプッシュ時の実行 テーブル削除時の手動実行 Ridgepoleを使ってみてよかったこと エクスポートが楽なため導入しやすい DBスキーマがGitH

2023年7月30日と31日にリブセンスのエンジニア有志で開発合宿に行ってきました。この記事ではその模様をお伝えします。 リブセンスでは過去、何度か開発合宿が開催されていました。 ↓過去のレポートはこちらです https://made.livesense.co.jp/entry/2019/04/06/094643 https://made.livesense.co.jp/entry/2019/12/03/070000 新型コロナウイルスの流行などの事情により、2019年を最後にしばらく中断していましたが、この度再開することができました。 今回は開発合宿プランがあるということもあり、前回と同じくおんやど恵を利用しました。 おんやど恵のHP 1日目 湯河原駅で集合し、駅の近くでお昼ご飯を食べたあとバスでおんやど恵に向かいました。 開発スタート 開発用の部屋として宿の宴会場を貸し切りにしました。

はじめに CIの概要 出てきた課題と対策 ライブラリのtimeout値が固定値な上に短い ドキュメントにないパラメータがダマで増えた モニターのゾンビ化 想定したように設定が反映されずに手動で変更 YAMLのdiffツール(dyff)の自己主張が激しい 結局CI化するべきだったのか？ 得られたメリット 正直な感想と今後 はじめに インフラGの@yjszkです。先日は青森競輪と盛岡競馬に行ってきて負けました、盛岡のジャンボ焼き鳥が美味しかったです。 さて、前回の記事ではCronitorというサービスのコード化と、CIの構築を行ったことを書きました。 それを実際に運用してみたところ、いくつかの問題が発生しました。今回は、それに対して、現在進行形で苦労している話を書きます。 CIの概要 前回の記事にあるように、CIを構築しました。 GitHub Actionsを使用し、PRにコミットが積まれると

マッハバイトで絶賛進行中のシステムのAWS移行にあわせ、開発者向けのAWS勉強会を開催しました。 今回の記事では勉強会の模様を紹介します。 なぜ勉強会をすることになったのか？ マッハバイトでは、システムのオンプレからAWSへの移行をすすめています。この移行はAWSの知見があるインフラGのメンバー全員+マッハバイトの一部メンバーという構成で取り組んでいます。 made.livesense.co.jp made.livesense.co.jp AWS上で動いているシステムが増えていく中で、AWSの知識量が人によって大きく差があり、AWSまわりを触れるアプリケーションエンジニアが一部に限られた状態になりかけていました。 このまま一部の人だけAWSを理解している状態が続くのはまずそうだ、という認識がチーム内で生まれ始めたため、インフラGのメンバーが中心になって社内AWS勉強会を開催することになりま