タグ

ブックマーク / techblog.lclco.com (11)

  • CodePipeline/CodeBuild/ECR/ECS/Fargateのコンテナデプロイ基盤を構築してみました - LCL Engineers' Blog

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

    CodePipeline/CodeBuild/ECR/ECS/Fargateのコンテナデプロイ基盤を構築してみました - LCL Engineers' Blog
  • capistrano-bundle_rsyncを利用したデプロイ方式に変更しました - LCL Engineers' Blog

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

    capistrano-bundle_rsyncを利用したデプロイ方式に変更しました - LCL Engineers' Blog
  • AWS EC2インスタンスの停止忘れを防止する - LCL Engineers' Blog

    Webエンジニアの森脇です。 LCLでは、普段使わないテストサーバなど常時稼働が不要なEC2インスタンスは、必要に応じて手動で起動・停止する運用にしています。が、停止を忘れて起動したままになっているということが、時々発生してしまっています。 大した金額ではないですが無駄は無駄なので、AWS CLIの勉強会を兼ねて、停止忘れを防止する仕組みを作りました。 仕組みの概要 AWS CLIを利用して、常時稼働が不要なインスタンスのステータスを定期的に取得し、"起動中"であればチャットへ通知します。 手順 インスタンスへのタグの付与 常時稼働が不要なインスタンスを識別するために、対象インスタンスには「env = spot」というタグを付与しました。 稼働中のインスタンスを取得 AWS CLIで対象インスタンスで稼働中のインスタンスのみを抽出します。 aws ec2 describe-instance

    AWS EC2インスタンスの停止忘れを防止する - LCL Engineers' Blog
  • 突撃!隣のフレックスタイム - LCL Engineers' Blog

    モバイルアプリエンジニアの山下です。 先日の記事でも少し触れられていましたが、LCLでは先月からフレックスタイムがトライアル導入されました。 techblog.lclco.com 今回は、エンジニアメンバーへどのような使い方をしたかをアンケートで聞いてみたのでお届けしたいと思います。 フレックスタイムを導入済み、または検討している方やLCLに興味を持っていただけているエンジニアさんの参考になれば幸いです。 フレックスタイムのルール 以下のルールで運用されています。 07:00 ~ 21:00の間で勤務可能 コアタイムは10:00~15:00 1日の中でコアタイムは必ず勤務する 1ヶ月単位では月の所定労働時間を必ず勤務する 他にも仕事の進捗などに悪い影響が起きないように細かいルールが少しだけありますが、偏りなく利用すれば問題がないため割愛します。 このルールにより、以下のような働き方が可能に

    突撃!隣のフレックスタイム - LCL Engineers' Blog
  • E2EテストをPhantomJSから、Puppeteer + Headless Chromeへ移行しました - LCL Engineers' Blog

    Webエンジニアの森脇です。LCLでは、以前より「Capybara + PhantomJS」でE2Eテストを行っていましたが、「Puppeteer + Headless Chrome」へ変更しました。 元々は、軽くPuppeteerを触ってみるだけのつもりでしたが、できが良く格的にE2Eテストへ導入することにしました。 記事では、変更の経緯や、PuppeteerでE2Eテストを実装する上でのTIPSを紹介します。なお、Capybara + PhantomJSを利用したE2Eテストは、以下の記事でご紹介しております。 techblog.lclco.com 変更の経緯 PhantomJSは古めのWebkitをベースにしているため、一部のCSSがうまく適用されず、Headless Chromeへ移行を以前より考えていました。そんな中、PhantomJSの開発が終了したこともあり、移行すること

    E2EテストをPhantomJSから、Puppeteer + Headless Chromeへ移行しました - LCL Engineers' Blog
  • Zeplinを導入してデザイナーとエンジニアの連携をもっとスムーズに - LCL Engineers' Blog

    フロントエンドエンジニアの岡田です。 LCLでは、デザイナーとエンジニアの連携をスムーズにするために、Zeplinを導入しました。 今回は、導入にあたって行ったことをまとめました。 デザイン&コーディング体制 Zeplin導入前に使っていたツール Zeplinとは Zeplin導入の流れ インストール チームへの普及 最初はモブプロ方式の勉強会 みんなで触ってみる Chatworkにグループを作成 有料プラン契約 STARTERプランでできること その他のプランとの比較 Adobe Creative Cloud Extractと比べて良いところ テキスト情報・CSS情報がコピーできる デザインカンプへのコメントが簡単 透明にしてブラウザに重ねられる その他 課題 Photoshopのアートボードが必要 Zeplin内で表示の切り替えができない まとめ デザイン&コーディング体制 LCLでは

    Zeplinを導入してデザイナーとエンジニアの連携をもっとスムーズに - LCL Engineers' Blog
  • iTerm2とfish shellを使ったターミナル環境構築のはじめの一歩 - LCL Engineers' Blog

    モバイルアプリエンジニアの山下(@yamshta)です。 先日、エンジニアチームでの勉強会にてターミナルを題材としたハンズオンを行いました。 techblog.lclco.com 今回はその際に共有した業務効率を上げるためのターミナル環境構築について紹介します。 以下に心当たりのある方は一緒に構築していきましょう。 ターミナルがモノクロ ターミナルをいい感じにしたいけどよくわからない ターミナルにこだわりが無い iTerm2 まずはじめにプリインストールされているターミナルとはお別れをします。 ターミナルアプリには、便利な機能が含まれている『iTerm2』を使うのがオススメです。こだわりが無い人こそ、とりあえずこれを使っておきましょう。 iTerm2 - macOS Terminal Replacement 上記のページからダウンロードして、解凍したものをApplicationフォルダに移

    iTerm2とfish shellを使ったターミナル環境構築のはじめの一歩 - LCL Engineers' Blog
  • Webサービスの品質向上のために導入しているサービス・ツールまとめ - LCL Engineers' Blog

    LCLが運営しているWebサービスは、品質向上のために、複数のサービスやツールを利用しています。今回はそれらのサービス・ツールをまとめてご紹介します。 品質向上のためのプロセス それぞれのサービス・ツールは以下のタイミングで利用しています。 各サービス・ツールの紹介 各サービス・ツールについて、一つずつご紹介します。 なお、今回はコードレビューや手動テストについては取り上げません。 SideCI SideCIとは、コードレビューを自動化してくれるサービスです。GitHubのプルリクエストを自動で解析して指摘してくれます。 Ruby, PHP, JavaScript, CSS, Java, Python, Go, Swiftなどに対応しているようです(2018/02/15現在)。 詳細は以下の記事でご紹介しています。 techblog.lclco.com SideCIは、プルリクエストが作ら

    Webサービスの品質向上のために導入しているサービス・ツールまとめ - LCL Engineers' Blog
  • Railsアプリケーションで採用しているDBスキーマ設計ガイドライン - LCL Engineers' Blog

    Webエンジニアの森脇です。 Railsアプリケーションで採用しているDB設計(スキーマ定義)について紹介します。 ※ Railsでは当たり前もの、Railsに依存していない内容も含んでいます。 前提 環境違えば、採用するルールも異なると思いますので、まずは弊社で利用している環境を記載します。 DBはPostgreSQL 9.x 開発言語は、Rails 4.x,5.xを利用 命名ルール Railsの規約に沿う命名を採用しています。DB設計にこだわりがあるメンバーにとっては、異論があるルールもあるのですが、アプリケーション開発の生産性も考慮しRailsの規約に寄り添うのがよいと判断をしました。 テーブル 動詞は使用せず、名詞とする 複数形とする 1:n のテーブル名は「単数形_複数形」 とする n:n のテーブル名は「複数形_複数形」とする カラム カラム名にテーブル名のprefixは付与し

    Railsアプリケーションで採用しているDBスキーマ設計ガイドライン - LCL Engineers' Blog
  • コードレビューの機械的な指摘はSideCIに任せる - LCL Engineers' Blog

    コードレビューを自動化してくれるSideCIを導入しました。GitHubのプルリクエストを自動で解析して指摘してくれます。 主にRubyを使用しているのでRuboCopを筆頭に解析ツールが豊富に揃っているのは助かっています。 導入の経緯 もともとRuboCop, JSHint, ESLintは使用しており主にローカルで実行して個人個人で修正対応していました。 RuboCopはJenkinsのJOBを走らせていましたが、毎回リポジトリ全体に対して実行すると時間がかかっていたり、わざわざJenkinsの結果を確認する必要がありプルリクエストベースの開発プロセスから外れているためあまり効率が良いものではありませんでした。 そこで自前でやるよりサービスを利用したほうが開発にリソースを投入できるということもあり以前から気になっていたSideCIを導入してみることにしました。 導入してみて良かったとこ

    コードレビューの機械的な指摘はSideCIに任せる - LCL Engineers' Blog
  • PostgreSQLでWebサービスを運用するためにやっていること - LCL 開発者ブログ

    弊社では、RDBMSにPostgreSQLを利用して数年間サービスを運営しています。 PostgreSQLMySQLと違って、Webサービスでの運用事例をあまり見かけないので、今回は弊社サービスの「夜行バス比較なび 」でどのように運用しているかを紹介いたします。 システムの特徴 ユーザからのアクセスは、9割が参照処理。 データはバッチ処理で、随時 ( 毎分 ) 更新されている。 参照SQLの結果はmemcachedを利用してキャッシュをしているが、データの更新頻度が高いため長時間のキャッシュはしていない。 参照SQLは、集計処理が多いため比較的重いSQL。 参照対象となるテーブルのデータ量は、最大で数100万レコードと比較的少ない。 24/7で稼働。 構成 AWSのEC2上に、PostgreSQL 9.3を導入しています。c4系のインスタンスを使いたいので、RDSは使っていません。インス

    PostgreSQLでWebサービスを運用するためにやっていること - LCL 開発者ブログ
  • 1