はじめに 技術構成（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メー

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

はじめに イメージ 実行 フローチャート しんどいポイント 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個ほどもあった）を、社内のエンジニアで手分けして調査し、適切と思われるものに変換するためのデータをゴリゴリ作りました。 この記事では、近年大き

はじめに 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勉強会を開催することになりま

みなさん、プレビュー環境してますか？どうも、かたいなかです。 以前、記事や登壇でIstioベースのPreview環境の構築方法をご紹介しました。 made.livesense.co.jp 外向けに発表したものの、Istioの運用工数や学習コストがネックとなってしまい、実際の転職会議の開発環境の導入にはいたっていませんでした。 最近になってGateway APIの実装例も増えてきて、Istio以外にもプレビュー環境でのヘッダを元にしたルーティングの実現において、現実的な選択肢となりそうなツールが増えてきました。そこで、Gateway APIのEnvoyによる実装であるEnvoy Gatewayを用いて、サービスメッシュを使用しないプレビュー環境の構築を試してみたため、この記事では構成例をご紹介します。 なお、今回の記事の中ではプレビュー環境の説明等について前回の記事と同様の説明を再度する箇所

リブセンスVPoEの中野(etsxxx)です。 私はこれまでWorking Out Loud(WOL)というコミュニケーションスタイルを、所属した2チームで実践してきました。最初のチームでは7年、次のチームでは1年ほど運用しています。 最近、他のチームからも取り入れてみたいと相談されることがあったので、改めてWOLについて振り返りをしてみようと思い、この記事を書いています。 WOLとは？ 導入の経緯 1チーム目: WOLの原体験 2チーム目: 意図を持って始めたWOL WOLの導入を振り返る 導入前の課題感 実際にWOL導入初期にやったこと チャンネル削減 会話量を増やすための行動 WOL導入前後の比較 私が気をつけていたこと 積極的に絡みに行く 読み落としを責めない 長文をなるべく送らない 大事なメッセージは目立たせる スレッドが嫌いなことを言い続ける 集中したい時は、チャットを見ないで

はじめに LET運営の村山と毛利です。 社内の交流を活発にし、お互いの知識を伝搬する機会を設けるために、Livesense Engineer Talk（通称:LET）というチームを運営しています。 今回は、GitHub Copilot for Businessを社内導入して2ヶ月程経ったので、エンジニアにCopilotを使った感想を聞いてみました。 はじめに みんなの感想 ayumu838さん ここがよかった ここが惜しい 池谷さん ここがよかった ここが惜しい 赤坂さん ここがよかった ここが惜しい 中野さん ここがよかった ここが惜しい 富士谷さん ここがよかった ここが惜しい 渡辺さん ここがよかった ここが惜しい 鈴木さん ここがよかった ここが惜しい 今井さん ここがよかった ここが惜しい まとめ みんなの感想 みんなの感想をChatGPTに要約してもらうと、こんな感じになりまし

まえがき こんにちは、インフラグループの yjszk です。 インフラグループでは、Amazon Inspectorで検出された脆弱性への対応を定期的に行っています。 ただ、脆弱性情報を収集して適切な対応を行うプロセスは手作業です。作業が面倒であり、トイルとなっていました。 そこで、PythonとGitHub Actionsを使ってGitHub IssuesにAmazon Inspectorで検出した脆弱性情報を登録し、必要な対応内容がひと目でわかるようにしました。 この自動化により、より迅速な脆弱性対応が可能になりました。具体的には以下のようなIssueを自動作成しています。 Amazon Inspectorについて 概要は以下です。 EC2インスタンスにAmazon Inspector エージェントをインストールして、ネットワーク到達性や、プラットフォームの脆弱性を診断し、潜在的なセキ

インフラエンジニアの中野(etsxxx)です。 Slackで少し凝った機能・・・例えば簡単な演算ツールを作ったり、ChatOpsを行おうとすると、コードを書いて動かしたくなることがあります。しかし、やりたい処理は簡単だったとしても、従来は、”書いたコードをどこで動かすか”に悩んだものです。 Pipedreamはまさにその救世主となりうるサービスで、感銘を受けたので利用法の紹介記事を書いています。 ちなみに、この記事は元々2023年3月に書いたメモが元なので、スクリーンショットが古い部分があったらごめんなさいｗ Pipedream is 何？ Slackのスラッシュコマンドを作る 利用イメージ PipedreamでTrigger(入力)を準備 Slack管理画面でスラッシュコマンドの準備 PipedreamでPythonステップを追加 動作テスト 最後に雑多に感想を Pipedream is

はじめに ArgoCDを構成するコンポーネントについて ArgoCDのログ量問題に直面した背景 ロギングライブラリが複数あることによる苦労 ログレベルを調整した結果 おわりに はじめに インフラストラクチャーグループの @mom0tomo です。普段はマッハバイトのクラウド移行に取り組んだり、コーポレートサイトのCSS/JSと格闘したりしています。最近、少しずつ転職会議のKubernetes運用にも関わるようになりました。 転職会議では、KubernetesクラスターへのCI/CDツールとしてArgoCDを利用しています。 made.livesense.co.jp ArgoCDにはGUIがあるためアプリケーション開発者も親しみやすいなど利点が多いのですが、デフォルトで出力されるログが多く、必要以上にログデータを生成してしまうと言う問題がありました。とくにDatadogのようなログ分析ツール

こんにちは、かたいなかです。 みなさんが関わっているシステムでなぜか遅くて悩まされている処理はないでしょうか？ 最近、遅いAPIをDatadog Continuous Profilerを使用して調べました。どのように問題解決までつなげたかを記事にまとめます。 www.datadoghq.com TL;DR 特定のAPIが遅い問題が発覚 Continous Profiler導入 Continuous Profilerで計測してみると・・・ 問題修正 実際のところ まとめ 参考 TL;DR 遅い処理を改善しようと思ったらまずは計測してみること。 計測することで実は単純な問題であったことに気付けるケースがたくさんあります。また、的はずれな推測を元にでたらめな変更を繰り返してしまう事態を防げます。 通常のDatadog APMで原因がわからない場合には、Continuous Profilerで可視

はじめに ご無沙汰しています。転職会議事業部でエンジニアリングマネージャーと開発者をやっている落合です。もうすっかり春ですね。 さて、つい先ほどプレスリリースも発表されましたが、本日転職会議にてChatGPTのAPIを利用した企業口コミの要約コンテンツを掲載する新機能の試験提供を始めました。 prtimes.jp リリース速度優先でまだスマホでしか見られないのですが、こんな感じの画面になっています。もしご興味あれば、スマホでこちらからアクセスしてみてください。 リブセンスの口コミ要約キャプチャ さまざまなみなさんのご協力もあり、ChatGPTのAPI公開、検討開始から3週間ぐらいでなかなかいい感じに形にできそうだぞと喜んでいたのですが、リリースが見え始めた開発後半の夕方、機能リリースと合わせた広報戦略を練っていた企画陣から恐ろしい無茶振り相談が飛んできました。 企画のみなさん「機能リリース

リブセンスでデータエンジニアをしている富士谷です。 Software Designのデータベースに関連する特集記事を再構成した「データベース速攻入門 ～モデリングからSQLの書き方まで」が、2023年3月に発売されました。 gihyo.jp リブセンスがSoftware Design 2017年11月号に寄稿した「データ分析に効くSQL50本ノック」が、内容を更新して再掲載されました。 今回、再掲載にあたって、「SQL50本ノック」の内容の更新を私が担当しましたので、簡単に紹介します。 SQL50本ノック 「SQL50本ノック」は、SQL、特にSELECT文の演習問題集です。 PostgreSQLをDockerで立ち上げて、もっともシンプルな例から実行し、WHERE句、LIMIT句などを一つ一つ体験し、最後には、移動平均といった高度な文法を習得する事ができます。 これを読めば、SQLを使っ

大きなPull Requestのレビューがつらい 修正ファイル数が多いこと自体が問題なのではない 1つの内容に集中する 小さなPull Requestの作り方 リファクタリングの修正は気になっても別で出す Web API 1つに着目して実装を切り分ける 小さなPull Requestで作ったときのリリースの仕方 featureブランチを作って、そこから更にブランチを作っていく フィーチャートグルを使う 小さいPull Requestで小さくフィードバックをもらおう 大きなPull Requestのレビューがつらい 転職ドラフトでWebアプリケーションエンジニアをしている @iwtn です。 この記事ではチーム開発では当たり前になったレビューにおいて、修正されたファイルがたくさんあるとつらいよね、というお話と、その解決策を提示してみたいと思います。 昨今のWebアプリケーションなどのチーム開

こんにちは、インフラストラクチャーグループのyjszkです。2月から入社しました。 リブセンスにはバッチをECSとEventBridge Ruleで動かしている実装があります。EventBridge Ruleがなかなかの曲者で、UTCでしか時間を指定できません。 UTCで指定されたルールはいつ動くのかがわかりづらいですし、JSTでは1つのルールで済んだものがUTCでは2つ以上に分割されてしまうこともあります。 例えば、JSTで特定の曜日に10分ごとに実行するタスクがあるとします。 */10 * * * 0-3,5-6 * これがUTCだと3つになります。これはなかなかつらいです。 0/10 0-15 ? * 4 * 0/10 15-0 ? * 5 * 0/10 * ? * 1-3,6,7 * 一方、2022年11月にリリースされたAWSの新機能EventBridge Schedulerでは