はてなブックマーク

この記事はLCL Advent Calendar 2021 - 15日目です。 qiita.com バックエンドエンジニアの高良です。 LCLへの転職を機に沖縄から上京して早2年、地元と段違いの寒さにも段々と慣れてきました。 ここ最近ではRailsでの開発に加え、インフラ周りのちょっとした調整などの作業をすることも増えてきました。 その中で1点、実装方法の調査時に手間取った箇所があったので、解決のポイントを紹介しようかと思います。 SQS(FIFO)と連携しているLambdaのスケールアウト 現在海外航空券では、SQS(FIFO)+Lambdaが連携したバッチジョブが動いています。 techblog.lclco.com こちらは1日1回の実行としているのですが、条件によっては実行時間が1日を上回ってしまい、必要な処理が1日で完了しきれないという問題が発生しました。 この時Lambdaは1台

バックエンドエンジニアの星野です。 東京オリンピック2020が開幕されましたね。LCLは移転前のオフィスがオリンピック選手村に近い勝どきにあったので選手に親近感を覚えます。 さて、LCLではバックエンド開発のWebアプリケーションフレームワークとしてRuby on Railsを採用しています。 先日、Railsのアップデートや構成の更新をした際にCredential機能について見直す機会があったのでその知見を共有したいと思います。 tl;dr master.keyはGitリポジトリに含めない マルチステージビルドか--mount=type=secretを活用してDockerイメージにもmaster.keyを含めない Amazon ECSではSSMパラメータのSecureStringを利用して環境変数RAILS_MASTER_KEYを設定する Credential機能の概要 Railsはバー

この記事はLCL Advent Calendar 2021 - 1日目です。 qiita.com LCLとRailsバッチジョブ バックエンドエンジニアの星野です。今年のre:Inventは開催前の時点で大型のアップデート続いており本番で何が発表されるのか全く予想がつきません。 さて、LCLではこれまでRailsバッチジョブの実行基盤としてKuroko2を利用してきました。 Kuroko2については過去の記事を参照してください。 techblog.lclco.com Kuroko2はRuby on Railsを開発の中心に据えている私たちにとって使い勝手が良い一方で、 運用面で大きく2つの課題がありました。 バッチジョブの実行数や負荷状況に応じたEC2インスンタンスのオートスケーリングが出来ていない Kuroko2サーバーの自体のメンテナンスタスクが発生する 注: あくまでLCLでの運用ケ

はじめに バックエンドエンジニアの星野です。 最近、節電を意識して自宅のUbuntuサーバーを停止しました。 夏真っ盛りですが、電気代の値上げで自宅サーバーにとっては冬の時代です。 LCLではレガシー脱却の取り組みの一環としてRuby on Railsで作成された社内向け管理画面のアップデートを実施しました。 その際にRails 7リリース前後で登場した、importmap-railsとdartsass-railsを利用してフロントエンドツールチェインを更新しました。 tl;dr サードパーティのJaveScriptライブラリをImport maps経由で読み込みように変更しました。 SassのコンパイルをDart Sassに乗り換えました。 importamap-railsとdartsass-railsはRails 6.0以上で利用できるので最新のRailsではなくても利用できます。 レ

はじめに この記事はLCL Advent Calendar 2021 - 4日目です。 qiita.com バックエンドエンジニアの星野です。このアドベントカレンダー同じ人しかいないって?気のせいです。 LCLのバッチジョブ実行基盤解説記事の最後のエントリになります。 最終日はSQSとActive Jobについてです。この記事ではActive Jobそのものについては解説しませんのでRailsガイドを適宜参照してください。 railsguides.jp Ruby on Railsの非同期処理でActive Jobを使う場合はアダプターを選択する必要があります。 SidekiqやResqueなどRedisをバックエンドにしたアダプターが人気がありますがRedisの管理をしなければならず、シンプルにperform_laterしたいだけの要件に対して大掛かりになりすぎることがあります。*1 そこ

この記事はLCL Advent Calendar 2021 - 17日目です。 qiita.com フロントエンドエンジニアのsatoshioです。 先日弊社が提供しているバスツアー検索サービスでESLintおよびPrettierのバージョンアップ対応を行ったので、今回は対応の流れやそこで遭遇したエラーとその解決方法についてまとめます。 日帰り・宿泊バスツアーの人気格安プラン検索【バス比較なび】 目標 ESLintを最新のバージョンにアップグレードする Prettierを最新のバージョンにアップグレードする 準備 現状の確認 対応開始時点でのESLintの最新バージョンはv8.4.1、Prettierの最新バージョンはv2.5.1のようです。 一方で、バスツアー検索サービスで使用しているバージョンはというと... { "dependencies": { "nuxt": "2.15.8",

この記事はLCL Advent Calendar 2020 - 6日目です。 qiita.com ユーザに見えるところの開発が好きなモバイルアプリエンジニアの山下です。 業務ではモバイルアプリ以外にバックエンドやインフラを広く浅く担当していますが、チームの技術スキルが上がると共にキャッチアップする量が増えていき限界を感じつつあります(汗)最近は後者の比率も多く、その反動で個人的にwebサービスを作りたい思いが芽生えてきたので自粛期間中に流行のNext.jsを少し触っていました。 モバイルアプリのようにビルドを待つこともなければ、TypeScriptを使えばRailsのように型で消耗することもないので開発効率が良いですし、Vercelを使えば簡単に無料でホスティングしてくれるので最高の開発体験に感動しています。 とはいえ、生きたサイトを作るとなるとバックエンド(APIやDB)を用意する必要が

はじめに この記事はLCL Advent Calendar 2020 - 24日目です。 qiita.com リモートワークと外出自粛の組み合わせにより年の瀬をあまり感じていないバックエンドエンジニアの星野です。 LCLではAmazon ECSを活用しています。 その中でAmazon API GatewayのHTTP APIと組み合わせて使う機会があったので紹介したいと思います。 はじめにHTTP APIとREST APIの違い、それによるVPCリンクの挙動違いについてはクラスメソッドさんの記事によくまとまっていましたので参考にしてください。 dev.classmethod.jp dev.classmethod.jp システム構成図 システム構成図は次のようになります。 クラスメソッドさんの図とほぼ同じです本当にありがとうございました 外側からAPI Gateway、ECSサービスディスカ

この記事はLCL Advent Calendar 2020 - 23日目です。 qiita.com フロントエンドエンジニアの川辺です。 もうすっかり年末ですね。 年末は毎年ソワソワしているのですが、私事ですが今年は12月末に子供が生まれる予定なので例年以上にソワソワしています。 赤ちゃんを迎える準備に忙しい日々を送っています。 弊社では11月から新規案件をNext.jsで実装しているのですが、Next.jsについてあれこれ調べてる中でNext.js公式サイトでVS Codeでデバッグする方法についてのドキュメントを見つけたので今日はそれを紹介しようと思います。 ※(注記)npx create-next-appを実行してnextを開発する環境が既にできている前提で進めていきます。 ステップ1 Next.jsをデバッグモードで起動する まずはnextを起動する時にNODE_OPTIONS='--in

この記事はLCL Advent Calendar 2020 - 12日目の記事です。 qiita.com はじめに LCLのバックエンドエンジニアの古賀です。 本記事の内容は以下のような方を対象にしたdockerの初学者向けの記事になっています。 チームでdockerを使い始めたがよく分かっていない コマンドアレルギーなので理解が追いつかない 特にチームで使い始めて、ふわっと始めた方は最初が大変ですよね。 私も数年前にチームで環境構築をdockerへ移行したのですが 以下の点で最初の一歩が難儀でした。 ログがない(ように見える)ので何が起こっているのか分からない dockerコマンドが長くて覚えきれない 自分で環境作ってないので環境更新したいとき取っ掛かりがない ですが今では関連ツールがブラッシュアップされたり、界隈のナレッジがブログ化されたりなどして 非常にdockerを始めやすい環境に

この記事はLCL Advent Calendar 2020 - 7日目の記事です。 ご挨拶 バックエンドエンジニアの染谷です。 LCLでは2018年4月から、バス比較なびやバスツアー検索サービスなどの開発に携わっています。 普段使っている言語・フレームワークは下記の通りです。 Ruby on Rails Nuxt.js (Vue.js) React 技術開発部の中ではいまだに少数派ですが、開発マシンにはWindows 10を使用しています。 Windowsでは2020年の中旬くらいにWSL2という機能がリリースされました。 簡単にいうと「Macと同様のLinux開発環境がWindowsで構築できる」ものです。 WSL2とは Windows開発環境の革命です。 WSLの名を冠しますが、WSL1とは仕組みが全然違います。 簡単に言うと 「むっちゃ起動が早い仮想マシン(VM)」 です。 私のマシ

こんにちは。id:kasei_san です バス比較なびのバスツアー検索サービスにて、ブランチ毎にECS FargateでQA環境を自動生成する仕組みを格安で作成したので、ドヤりたくなり記事を書きました! 課題 バス比較なびのバスツアー検索サービス(以降「バスツアー」)では、動作確認環境が stage 環境しかありませんでした。 そのため、以下のような事象が発生し、デリバリー速度が低下するという課題がありました。 stageでの動作確認がボトルネックになり、、他の修正をstageに上げたり、リリースすることができない 大きい修正もすべて完了してからstageにあげていたので、手戻りが発生することがあった 解決方法 解決のためにチームで話し合い、ブランチ毎に環境があれば、待ちも発生せず、作りかけの時点で確認してもらうこともできる。となりました。 どういうものを作ったか このようなものを作成し

Androidアプリ兼バックエンドエンジニアの高橋です。 弊社のサービス「バス比較なび」では、たくさんのバス会社さんから頂いた高速バスデータを掲載していますが、バス会社さん間での「データの揺れ」が課題の一つとしてあります。 例えば、バスの「停車地」には以下のような表記揺れがあります。 A社 : JR東京駅八重洲南口 鍛冶橋駐車場 B社 : 八重洲口鍛冶橋駐車場<東京駅 八重洲南口> C社 : 東京駅八重洲南口 この状態では、停車地をGoogle Mapにマッピングしようとしても、難しいですよね。 実は、弊社ではこれまで手作業によってこういった名称を「名寄せ」しています。 上記の例でいうと、JR東京駅 八重洲南口 鍛冶橋駐車場 が名寄せ後の名称です。 データが蓄積されている現在では手作業でもある程度はカバーできますが、休日や長期連休などに対応できないので、現在停車地の名寄せ自動化に挑戦してい

Webエンジニアの森脇です。 LCLでは、DB設計変更で、DBマイグレーションをする際にシステム障害を回避するためのいくつか工夫をしています。今回は、その内容を簡単にご紹介いたします。 migration作成時の注意 ブランチ戦略 原則、migrationのブランチは独立させるようにしています。 migrationとコードのデプロイはタイミングを分けたほうが安全であり、さらに他のコード修正と混ぜると、切り戻し等がやりづらいくなるため 新規JOBなど既存コードに影響しない場合は、独立させなくても可 既存コードに影響を与えない migration実行後も既存コードで正常稼働するように、migrationを作成します。 以下にケース別の手順を紹介します。 テーブルの新規作成 テーブルの新規作成は特に意識することはありません。 ただし、既存テーブルへ外部キーを貼る場合は、後述の手順に従い注意が必要

バックエンドエンジニアの横塚です。 Railsで中規模以上のサービスを運用していると、大量のレコードやcsvをバッチで処理したい場面などが出てくると思います。 当たり前のように意識できている人も多いかと思いますが、今回はおさらいの意味も込めてバッチで大量データを扱うときに気をつけていることをまとめていこうと思います! 大量レコードに対して処理をするときはfind_eachやfind_in_batchesを使う DBからデータを取得してきて処理をしたい場合、eachで処理しようとすると対象データがすべてメモリに展開されてしまいますが、find_eachは1行ずつメモリに展開するため、レコード数を気にせず処理をすることができます。 User.each do |user| # なんか処理 end ↓ User.find_each do |user| # なんか処理 end また、find_in_

Androidアプリ兼バックエンドエンジニアの高橋です。(肩書き長い...!) GW終わってしまいましたね。自分は特に予定も立てていなかったので近場を散策したりMr. Robotという海外ドラマを見たりして時間を潰しました。 Mr. Robot、主人公がハッカーの話で面白そうと思って見たのですが、自分の知識では何をやっているのかさっぱりでした... この話が理解できるくらいの(ホワイトな)ハッカーになるべくこれから精進してまいります。 さて、入社してから2週間ほどAndroidアプリ版バス比較なびの開発をこなしてきたので、Androidの技術的な話がブログに書けるようになってきました。 今回はアプリのアーキテクチャをMVVMにしたという話をご紹介します。 現状のアーキテクチャ 現状のアーキテクチャを大雑把に図にすると、こんな感じになっています。 流れを解説すると、Activity/Frag

最近は花粉を避けるためにMTGがある日以外はリモートワークにしています。 モバイルアプリエンジニアの山下(@yamshta)です。 今回は先月から個人的に使い始めた『Notion』の紹介をします! Notionとは? Google Docs、Evernote、Trello、GitHub Wikiを合体させたようなサービスです。 非常に多機能ですが、デザインはシンプルで精錬されています。 Markdownが使え、Emojiを見出しで表現できるところがエンジニアには親しみやすいです。 一番はじめにNotionを知ったのは、イケてるプロダクトツールとドキュメントツールを探している時で、機能の多さと日本語対応していないことからチームで使うにはハードルが高いと思い、試していませんでした。 しかし、最近このサービスを個人で利用している記事を読み、実際に触ってみたところ、整理好きの私にとって最強のツール

こんにちは。バックエンドエンジニアの id:kasei-san です 最近は映画「リベリオン」を見たいのですが、配信しているサービスがTSUTAYAとU-NEXTしかなく、加入すべきか悩んでいます doga.hikakujoho.com 本日はHTTP キャッシュについて解説します 経緯 LCLではキャッシュサーバにVarnishを使用していますが、現在Fastlyへの移行を検討中です techblog.lclco.com 移行についての作業を任されたため、HTTP キャッシュについて勉強し直そうと思いこの記事を書きました! HTTPキャッシュとは そもそもHTTPキャッシュとは何でしょうか? HTTP上でのキャッシュについてのRFC RFC 7234 — HTTP/1.1: Caching (日本語訳) の序論によりますと... HTTP キャッシュ は、応答メッセージの局所的な格納域で

Webエンジニアの横塚です。 皆さんは情報共有ツールは利用しているでしょうか。 LCLエンジニアチームでは先日、以前から利用していたQiita:Teamからesa.ioに移行することにしました。 移行の背景と、実際に移行してみてどうだったかを簡単に紹介したいと思います。 teams.qiita.com docs.esa.io 移行しようと思った理由 Qiita:Teamは本来やりたかったwiki的な使い方にあまり合ってなかった LCLでは、システム仕様や、共有しておきたい知見、定例MTGの議事録などをQiita:Teamの記事に溜めてきました。記事には必ずタグ付けをしておき、関連記事はタグで検索できるようにしていました。しかし、記事が増えていくにつれ、その運用も限界を迎えていました。 記事が増えすぎた結果、タグが形骸化し、キーワード検索をするしかない状況になりました。 慣れている人はいいで

モバイルアプリエンジニアの山下(@yamshta)です。 LCLでは今年の1月にエンジニアブログ編集部を立ち上げ、『継続』を目標に1年間アウトプットし続けてきました。 techblog.lclco.com この記事は66本目となり、この投稿数は前年の約2倍となります。 個人としては22本を執筆することができ、執筆以外にも編集部の取り組みとして、他のメンバーへの執筆依頼や記事の校正にも挑戦しました。 執筆依頼は、普段ブログを書き慣れていないメンバーにもお願いするため、読者が読みやすい記事をスムーズに執筆できるように、個人的に気をつけていることを執筆ガイドラインとは別に共有しました。 今回は、その内容をこちらでも紹介したいと思います。 個人的な趣向に偏ってしまうため、あくまで参考程度に受け取っていただければと思います。 タイトル編 タイトルは最後に考える はじめにタイトルから考えようとするとそ

Webエンジニアの古賀です。LCLでは、障害対応の強化の一つとして多機能な通知機能を持つPagerDutyを導入しました。 組織的な対応シフト・フローが組めるようになり、精神的にとても安心できるようになったので紹介させていただきます。 pagerduty.digitalstacks.net 導入前の課題 LCLでは、Mackerelを利用して各サーバの監視しており、障害が発生するとチャットでエンジニアへTO(メンション)で通知をしていました。 この運用方法では、以下のような問題がありました。 全エンジニアへの通知のため、早めに気づくエンジニアが固定の担当になりがち TO(メンション)の重要度が高く、通常のやりとりで使いづらい 通知は一度しかこないため、他のチャットで埋もれてしまい見逃す可能性がある チャットでの障害通知では限界が見えてきて、何かいいサービスはないか検討していたところPage

Webエンジニアの川辺です。 今回はNode.jsでGoogle スプレッドシートを操作する際に使用したnode-google-spreadsheetの紹介をしたいと思います。 使用したバージョン Node.js: 8.11.3 node-google-spreadsheet: 2.0.6 準備 コード上からGoogleスプレッドシートを操作するため、シートへアクセスを許可するための準備が必要です。それでは順を追って進めていきます。 1. プロジェクトを作成 アクセスを許可するための認証情報を作成するためにまずプロジェクトを作ります。 Google Developers Console にアクセスし「プロジェクトを作成」をクリックしブロジェクトを作成します。 プロジェクトを作成するとこの画面が表示されます。 もし、プロジェクトが複数ある場合は今回作成したプロジェクトに切り替えてください。

モバイルアプリエンジニアの山下です。 先日の記事ではデプロイ基盤を構築し、Fargateへ自動デプロイすることができました。 techblog.lclco.com これによりEC2の操作を意識することなく、柔軟にコンテナ数をスケーリングできるようになったのですが、LCLの用途として一つ課題がありました。 Fargateはデプロイするたびにコンテナを作り変えるため毎回IPが変わってしまいます。 LCLでは各サービスでステージング環境やテスト環境を用意しており、これらは認証サーバを経由してアクセスするようにしています。 そのため、認証サーバ上のnginxの設定に参照先のIPをセットしているのですが、このままではデプロイされたタスクのIPを毎回手動で変更しなければいけません。 これではデプロイ自動化どころかFargateを運用することが難しいです。 そこで、ECSのサービスディスカバリという機能

フロントエンドエンジニアの岡田です。 10月27日から一週間は、読書週間だそうです。 みなさん、読書していますか? 以前ブログでもご紹介しましたが、エンジニアチームでは輪読会を行っています。 techblog.lclco.com この輪読会を、他のチームにも広げてみたら良かったので、まとめました。 輪読会のメンバー 読んだ本 輪読会の進め方 初回 2回目 よかったこと 締切があるのでダラダラ読みを防止できた いつもとは違った進め方や、違ったメンバーとの会話で理解が深まった 他のチームの課題が見えた 実際にエンジニアチームで導入してみることになった 終わりに 輪読会のメンバー 最初は、マネジメント系の本を読む会にするつもりだったので、メンターをしている人・する可能性がある人に声をかけて集めました。 メンバーは以下の5名です。 デザイナー ディレクター 総務・人事 アプリエンジニア フロントエ

Webエンジニアの川辺です。 今回はChromeのデベロッパーツールでスマホ表示を維持したまま別タブに遷移するという、ちょっとした便利ワザを紹介しようと思います。 手順 command + option + Iキー(Windowsの場合はF12キー)でデベロッパーツールを開きます。 デベロッパーツールの右上の設定メニューから「Settings」を選択します。 下の方に「Auto-open DevTools for popups」という設定項目があるのでチェックを付けます。 これでページをリロードをすると設定が反映されるため、別タブへ遷移するリンクを開いても新しいタブでデベロッパーツールが開かれるようになりました。 まとめ 過去にUser Agent Switcher, URL sniffer で無理やりスマホ表示にしたり、Death To _blank で別タブを開かないようにしたりもしま

モバイルアプリエンジニアの山下(@yamshta)です。 今回は、AWSの以下のサービスを用いてコンテナデプロイ基盤の構築を試してみました。 CodePipeline CodeBuild ECR ECS Fargate AWSのドキュメントは丁寧で情報も豊富ですが、サービス毎に手順が書かれているため一連の流れをまとめました。CLIでの操作のみで手順を進めています。 なぜアプリエンジニアがデプロイ基盤を構築するのか 疑問に思った方もいらっしゃると思うので手短に書かせていただきます。 LCLのエンジニアチームはスペシャリスト集団というよりはゼネラリスト集団に近く、特定の技術に縛られない文化とそれを推奨する環境になっています。そのため、メインに扱う技術力も伸ばしながらも別の技術を習得することができます。 今回の経緯ですが、私個人としてはインフラには興味がありませんでした。しかし、Dockerは環

Webエンジニアの森脇です。LCLでは、Capitranoを利用してRailsアプリケーションのデプロイを行っていましたが、「capistrano-bundle_rsync」を利用する方式に変更しましたので、背景含めて紹介いたします。 デプロイの概要 capistranoを利用したデプロイでは、デプロイサーバではcapistranoを実行し、各Webサーバへsshでログインし、各種デプロイ関連処理を行います。 このデプロイ方式では、以下の問題がありました。 デプロイ中は各Webサーバのリソースを多く消費してしまうため、アクセスが多いときはデプロイができない デプロイ時間が、Webサーバのスペックへ依存してしまう。 そこで、デプロイサーバでbundle install,precompileを行い、各Webサーバにrsyncで配布する方式に変更しました。 実現方法 capistranoを拡張し

Webエンジニアの森脇です。現在、障害通知の最適化を進めており、その第一弾としてMackerelのアラートグループ機能を利用して、障害通知の抑制をしました。手軽に実現ができ、便利だったので紹介します。 当初の課題 LCLでは、Mackerelを利用して各サーバのメトリクス監視やサービスの外形監視をしています。アラートが発生するとチャットへ通知していますが、大規模な障害発生した場合は、以下のようにアラート通知でチャットが埋まってしまっていました。 チャットがアラート通知で埋まってしまうことにより、障害対応の妨げになる問題が多く発生していました。 障害対応のやりとりをしても、アラート通知ですぐに流れてしまう 大量の通知がノイズとなり、障害対応への集中を削がれる OK/NGのアラートが個別に通知され、すべてOK状態になったかチャット上で判断しづらい すぐに解決策が見つからず放置になっていましたが