PagerDutyを導入して障害対応の体制と運用ルールを確立しました - LCL Engineers' Blog
Webエンジニアの古賀です。LCLでは、障害対応の強化の一つとして多機能な通知機能を持つPagerDutyを導入しました。 組織的な対応シフト・フローが組めるようになり、精神的にとても安心できるようになったので紹介させていただきます。 pagerduty.digitalstacks.net 導入前の課題 LCLでは、Mackerelを利用して各サーバの監視しており、障害が発生するとチャットでエンジニアへTO(メンション）で通知をしていました。 この運用方法では、以下のような問題がありました。 全エンジニアへの通知のため、早めに気づくエンジニアが固定の担当になりがち TO（メンション）の重要度が高く、通常のやりとりで使いづらい 通知は一度しかこないため、他のチャットで埋もれてしまい見逃す可能性がある チャットでの障害通知では限界が見えてきて、何かいいサービスはないか検討していたところPage
CodePipeline/CodeBuild/ECR/ECS/Fargateのコンテナデプロイ基盤を構築してみました - LCL Engineers' Blog
モバイルアプリエンジニアの山下（@yamshta）です。 今回は、AWSの以下のサービスを用いてコンテナデプロイ基盤の構築を試してみました。 CodePipeline CodeBuild ECR ECS Fargate AWSのドキュメントは丁寧で情報も豊富ですが、サービス毎に手順が書かれているため一連の流れをまとめました。CLIでの操作のみで手順を進めています。 なぜアプリエンジニアがデプロイ基盤を構築するのか 疑問に思った方もいらっしゃると思うので手短に書かせていただきます。 LCLのエンジニアチームはスペシャリスト集団というよりはゼネラリスト集団に近く、特定の技術に縛られない文化とそれを推奨する環境になっています。そのため、メインに扱う技術力も伸ばしながらも別の技術を習得することができます。 今回の経緯ですが、私個人としてはインフラには興味がありませんでした。しかし、Dockerは環
AWS EC2インスタンスの停止忘れを防止する - LCL Engineers' Blog
Webエンジニアの森脇です。 LCLでは、普段使わないテストサーバなど常時稼働が不要なEC2インスタンスは、必要に応じて手動で起動・停止する運用にしています。が、停止を忘れて起動したままになっているということが、時々発生してしまっています。 大した金額ではないですが無駄は無駄なので、AWS CLIの勉強会を兼ねて、停止忘れを防止する仕組みを作りました。 仕組みの概要 AWS CLIを利用して、常時稼働が不要なインスタンスのステータスを定期的に取得し、"起動中"であればチャットへ通知します。 手順 インスタンスへのタグの付与 常時稼働が不要なインスタンスを識別するために、対象インスタンスには「env = spot」というタグを付与しました。 稼働中のインスタンスを取得 AWS CLIで対象インスタンスで稼働中のインスタンスのみを抽出します。 aws ec2 describe-instance
地味に面倒なブランチ作成〜WIPプルリクエストまでをコマンド1つで行う - LCL Engineers' Blog
フロントエンドエンジニアの岡田です。 やる気がでない時の最良の方法は、「とりあえず始めてみる」ことだと聞いたことがあります。 今回は、やる気がでないときでもコマンドを1つ叩くだけで、ブランチ作成〜WIPプルリクエストまで作ってくれるように設定をしましたのでご紹介します。 WIPプルリクエストを作るまでにすること WIPプルリクエストを作るまでには、以下のことをしています。 masterをチェックアウト＆プル ブランチを作成 空のコミットを作成してプッシュ プルリクエストの作成 ラベルを付ける 手順が多い上に、私が普段使っているSourceTreeでは、3. の空のコミットが作れません。そのため、ターミナルで操作しなければならず、面倒でした。 そんな時に同じチームの人が教えてくれた以下の記事を試してみました。 qiita.com すごく便利です…！ これはぜひ使いたいと思い、さらに以下の機能
ALBのログをEmbulk + BigQuery + Redashで可視化する - LCL Engineers' Blog
Webエンジニアの森脇です。 LCLでは、AWS ALBのアクセスログを分析し、各種KPIを定期的に確認しています。今回は、Embulk + BigQuery + Redashを利用してのログ分析の事例について紹介したいと思います。 概要 AWS ALBのアクセスログは、S3へ記録されます。S3へ記録されたログを、fluentd / Embulk を利用して Elasticsearch / BigQuery へ格納しています。 Elasticsearchは、短期的なログの解析を目的としており、Kibanaを使用して予期せぬアクセスが発生した場合の調査等に利用しています。ログは一定期間を過ぎると破棄しています。 BigQueryは、長期的なログの保存・解析を目的としており、ログは永続的に保存しています。 準備 以下の流れでやっていきます。 ALBのアクセスログを有効化する BigQueryテ
自動タイムトラッキングツールのGTMを手動のTogglの結果と比較してみた - LCL Engineers' Blog
フロントエンドエンジニアの岡田です。 エンジニアは工数を出す機会が多いと思いますが、みなさんはどのようなツールを使っていますか？ 私は数年前から、Togglというツールを使って計測しています。 仕事を始める前にはボタンをポチッと押し、終わったらポチッと止める。 Togglの前に使っていたツールを合わせると5年以上このスタイルで仕事をしているため、今ではすっかり習慣になっています。 ただ、手動での計測は、以下のデメリットがあります。 押し忘れたり、止め忘れることもたまにある 突然話しかけられた時など、切り替えるのが面倒 そこで自動で計測ができる、GTMというツールを導入し、使い慣れたTogglと結果を比較してみました。 Togglとは GTM（Git Time Metric）とは GTM導入方法 インストール エディタプラグインのインストール 初期化 比較方法と集計手順 Toggl GTM
ChatWork Webhookを利用したデプロイフロー - LCL Engineers' Blog
Webエンジニアの森脇です。 LCLでは、ChatWork + Hubotを利用してデプロイをしていましたが、ChatWorkがWebhookに対応したため、Hubotを廃止しました。ChatWork Webhookを利用して、どのようなデプロイフローとなっているかを紹介します。 なお、Hubotを利用した構成は過去のブログに記載しています。 techblog.lclco.com 変更理由 Hubotを利用した構成でも、そこまで困ってはいなかったのですが、強いて言えば以下の理由があります。 Webhookではないため、特定のルームをChatwork APIでポーリングして発言のを検知する必要がある API呼び出し回数に制限があるため、ポーリング間隔を長くする必要があり、発言してからBotが反応するまでタイムラグがある 今後の拡張のため、慣れているRubyを使いたかった 構成 EC2上に、W
Dangerの指摘をChatWorkに流してリリースのミスを防ぐ - LCL Engineers' Blog
モバイルアプリエンジニアの山下です。 LCLでは作業中のPull Reqeustが誤マージされるのを防ぐため、Pull Requestのステータスをラベルで管理しています。 ラベルは「WIP」と「ready for release」の2つあり、マージするためには「ready for release」を付ける必要があります。 「ready for release」を付けられたPull RequestはChatWorkに通知され、開発部のメンバーへ周知されるようになっています。 今回はこの通知に先日導入したDangerの指摘を一緒に流し、指摘事項を全員が確認できるようにしてみました。 それでは実装例とGitHub Webhookの効率的なデバッグ方法を紹介していきます。 実装 GitHub Webhookで送られたJSONからDangerのコメントを取得して特定のルームに通知します。 今回は以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
