タグ

運用に関するpaulowniaのブックマーク (106)

  • GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる

    GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyRuby on Railsをアップデートし続けていることを今年(2023年)4月に明らかにしています。 参考:GitHubは200万行規模のRailsアプリケーションであり、毎週RailsRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up

    GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
  • ソフトウェアはなぜバージョンアップしなければならないのか - Qiita

    はじめに 社内インフラの運用担当者にとってソフトウェアのバージョンアップは地味な割に大変な業務です。 特に社内のオンプレサーバで動いているようなソフトウェアの場合、バージョンアップに伴う諸々の調整をそのソフトウェアを利用している各部署と行う必要があります。 そんなときに「今は忙しいからバージョンアップを先送りしてほしい」「このバージョンはスキップしてもよいのでは?」なんて声が各部署から聞こえてきます。バージョンアップの価値を各部署に理解してもらうのは大変です。 この文章はそんな時になぜバージョンアップしなければならないのかを上司や各部署のマネージャに伝えるために書きます。 ソフトウェアの有効期限は2-5年 まず、第一に、ソフトウェアというものは無限に使えるわけではなく、一定の有効期限があり、それを過ぎると徐々に動かなくなってきます。俗にいう「何もしてないのに動かなくなった問題」です。 なぜ

    ソフトウェアはなぜバージョンアップしなければならないのか - Qiita
  • オンコールアラートアンチパターン - ださろぐ@はてな

    オンコールアラートを設定しようと考えた際に考慮すべき点を自分なりにアンチパターンとしてまとめたなにかです。 ホワイトボックスモニタリングにより得られたメトリクス、ログなどからアラーティングを行う、または併用する環境を想定しています、ブラックボックスモニタリングによるアラート、SLOベースのアラートのみでうまく運用されているサービスにはあてはまらないと考えてます。 参考書籍は色々あり、最後に記載していますが提示されてるプラクティス通りではないものもあります 。自組織、システムにあった設計をしましょう。 システムの監視がまったくありませんみたいな状況であればまずはサービスのURLに対する外形監視からはじめましょう。 言葉の定義 アンチパターン サービスに対する外形監視が設定されていない アラートを受け取って直ちに何かアクションを行う必要がない アラートに対応するrunbookが存在しない 自動

    オンコールアラートアンチパターン - ださろぐ@はてな
  • 自宅の回線が時間によってめちゃくちゃ遅くなるのをMackerelとSpeedtest CLIで可視化した | DevelopersIO

    結果 こうなりました(結論からさらすスタイル)。 いまの御時世の固定回線で 下り 3Mbps って何ですかね??? というのは実は題ではなくて、このようなグラフを作ることがこの記事の題です。 背景 状況については冒頭の概要に書いたとおりなのですが、とにかく自宅のネットワーク回線を定期的に測定して可視化することを試みました。 ちなみに我が家は古い賃貸集合住宅で VDSL なので、上限は 100Mbps になります。それでもそこそこ快適で、特に不満もなかったのですが1、今月に入った辺りから急に回線状況の悪い時間帯に出くわすようになってしまいました。 改善策をとるまえにまずは計測、ということで、今回の試みとなったわけです。 仕組み ざっくりいうと、 自宅の Windows PC に Hyper-V で Linux を動作させ その Ubuntu にmackerel-agentを導入し 10

    自宅の回線が時間によってめちゃくちゃ遅くなるのをMackerelとSpeedtest CLIで可視化した | DevelopersIO
  • 「エーペックス」の仕組み:開発者によるサーバーとネットコードの解説

    これは、とある「エーペックス」のプロプレイヤーのネットワーク経路(レイテンシーを表示しています)です。彼のインターネットモデムから、私たちのサーバーへと到達しています。インターネット接続の当の状態を判断するため、私たちは何度も調査を行います。最善の状態であれば、彼は31msのレイテンシーでゲームを楽しめていることが見て取れますね。ですが最悪の場合だと、522ms付近です。つまりこの場合だと、接続に500msもの振れ幅があるため、ゲームの遊び心地はかなり悪いということです。彼のローカルISPネットワークの接続は不安定ですが、平均を見てみると非常に稀なケースであることがわかります(平均が31mで、最低値が264ms。たまたま起きたのでしょう)。しかしその後、ローカルのISPとISP1の間でレイテンシーが急増しています。これはプレイヤーとゲームサーバーの間のノードの一つです。この二つの間でパケ

    「エーペックス」の仕組み:開発者によるサーバーとネットコードの解説
  • 脆弱性対応(Heartbleed)の責任の所在 東京地判令元.12.20(平29ワ6203) - IT・システム判例メモ

    クレジットカード情報漏えい事故に関し,その原因の一つと考えられる脆弱性対応が運用保守業務に含まれていたか否かが争われた事例。 事案の概要 Xは,Xの運営する通販サイト(件サイト)を第三者に開発委託し,運用していたが,その後,2013年1月ころまでに,Yに対し,件サイトの運用業務を月額20万円で委託した(件契約)。件サイトはEC-CUBEで作られていた。なお,XからYへの業務委託に関し,契約書は作成されておらず,注文書には「件サイトの運用,保守管理」「EC-CUBEカスタマイズ」としか記載されていない。 2014年4月には,OpenSSL*1の脆弱性があることが公表されたが*2,件サイトでは,OpenSSLが用いられていた。 2015年5月ころ,Xは,決済代行会社から件サイトからXの顧客情報(クレジットカード情報を含む)が漏えいしている懸念があるとの連絡を受け(件情報漏えい)

    脆弱性対応(Heartbleed)の責任の所在 東京地判令元.12.20(平29ワ6203) - IT・システム判例メモ
  • WordPressを運用中のサーバがまるごとPHPマルウェアに感染していた時の対応メモ - Qiita

    (2021.1.26 追記) 稿の続きを書きました。 時系列で見る:WordPressを運用中のサーバが丸ごとPHPマルウェアに感染する流れ https://qiita.com/Ayutanalects/items/e7919afadc7d8394820f 制作会社から「自社で管理中のサイトがおかしい」との連絡を受けて、 中をのぞいたら、PHP製の複数種類のマルウェアに感染していたので対応をメモ。 以下の内容は、あくまでも自分の対応時のものです。 攻撃者がスクリプトを変更すれば同じ方法では検出できなくなるのでご注意ください。 初期状態 症状 自社管理中のWordPressサイトにアクセスすると、全く知らないサイトにリダイレクトされる 今回は allc〇〇ling.shop というEC風サイト。Kasperskyを使っていると、「警察機関指定の危険サイト」の警告あり https://sup

    WordPressを運用中のサーバがまるごとPHPマルウェアに感染していた時の対応メモ - Qiita
  • コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita

    課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可

    コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
  • あと2時間でElastiCacheのメモリが枯渇!そのときあなたは何をしますか?

    突然ですが... あなたは、あるゲームプロジェクト番リリース2日前にサーバエンジニアとしてJOINしました。いざリリースを迎えたとき、ElastiCacheのメモリが突然危険域を超え、さらにあと2時間で枯渇しそうな状況になりました。 さて、この状況におかれたあなたは何をしますか? はじめに モバイルゲームのシステムは新しいイベントをopenするとトラフィックが2倍、3倍、時には普段の10倍以上来ることがあり、トラフィックの変動が非常に大きい特性があります。 新しいゲームのリリース時はより顕著で、想定以上のトラフィックが来ることもしばしばあります。 この記事は、あるゲームプロジェクト番リリース時に大規模トラフィックが来た際のサーバトラブルを題材に、 どのような観点で問題を切り分けていったのか、トラブルシュートのプロセス どのような準備(負荷テスト)をしていれば防げるのか という話をし

    あと2時間でElastiCacheのメモリが枯渇!そのときあなたは何をしますか?
  • Telegraf open Source Server Agent | InfluxDB

    What is InfluxDB? Build real-time applications for analytics, IoT, and cloud-native services in less time with less code using InfluxDB. Find the right product

    Telegraf open Source Server Agent | InfluxDB
  • blog.kabuctl.run

  • 分散アプリケーションの異常の原因を即時に診断するための手法の構想 / Causality Tracing in Distributed Applications

    分散アプリケーションの異常の原因を即時に診断するための手法の構想 / Causality Tracing in Distributed Applications

    分散アプリケーションの異常の原因を即時に診断するための手法の構想 / Causality Tracing in Distributed Applications
  • PrometheusからcAdvisorのメトリクスを取得する ~docker runで立ち上げ~ - Qiita

    はじめに Kubernetesの監視について調べた時、cAdvisorを使う必要がありそうだと思ったのですが、cAdvisorのことをよく理解しておらず、「Kubernetesを立ち上げたら一緒に立ち上がったりするもの?」などと考えていました。このままではマズイので、cAdvisorのことを使い方から調べました。ここでは最低限cAdvisorを動かしてPrometheus(+Grafana)でメトリクスを取得できるようにします。 cAdvisorとは cAdvisor(Container Advisor)は、稼働中のコンテナの情報を集め出力し、リソースとパフォーマンス状況を教えてくれるツールです。取得するリソースは各コンテナの稼働状況(running,stoppedなど)、CPUやメモリの使用量などです。 公式のgithubページはこちらです。 cAdvisorを起動 cAdvisorはd

    PrometheusからcAdvisorのメトリクスを取得する ~docker runで立ち上げ~ - Qiita
  • Labeled Tab-separated Values (LTSV)

    Description Labeled Tab-separated Values (LTSV) format is a variant of Tab-separated Values (TSV). Each record in a LTSV file is represented as a single line. Each field is separated by TAB and has a label and a value. The label and the value have been separated by ':'. With the LTSV format, you can parse each line by spliting with TAB (like original TSV format) easily, and extend any fields with

    Labeled Tab-separated Values (LTSV)
    paulownia
    paulownia 2019/12/27
    ログ
  • SELECT文で本番環境を落としたお話 - Qiita

    (この記事は 地平線に行く とのマルチポストです) 番環境でやらかしちゃった人 Advent Calendarで、このパターンのやらかしはなかったのでキーボードを叩くことにしました。 番外編のつもりでお楽しみください。 この記事が、新たな障害発生を防ぐことにつながれば幸いです。 何をやったのか ある日、ちょっとした調査のために番データベースのデータを確認することになりました。 (個人情報が格納されているようなシステムではなかったので、必要であれば番データベースへのアクセスが許されていました) もしメンテナンスがあればそのタイミングでやればよかったのですが、直近では特に予定はないとのことでした。そのため、システムが動いている状態のまま作業をすることにしました。 ごく単純な SELECT を実行するだけのつもりだったので、システムに影響がないと判断したためです。 その際、万が一コピペをミ

    SELECT文で本番環境を落としたお話 - Qiita
    paulownia
    paulownia 2019/12/26
    笑っちゃいけないけど、くそ笑った
  • 未だ現役なPerl5.8 & MySQL4.0とどう戦うか? ライブドアブログが生んだカオスとレガシーからの脱却

    未だ現役なPerl5.8 & MySQL4.0とどう戦うか? ライブドアブログが生んだカオスとレガシーからの脱却 Inside of Blog 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦 #2/2 2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINE技術の深堀りを、2日目は「Production」をテーマに、Web開発技術UI/UXプロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦」に登壇したのはLINE 開発Bチームの大森貴博氏。後半パートとなる今回は、現役で稼

    未だ現役なPerl5.8 & MySQL4.0とどう戦うか? ライブドアブログが生んだカオスとレガシーからの脱却
  • [AWS] Amazon SESのアカウントが止められちゃった話 - Qiita

    この記事は番環境でやらかしちゃった人のアドベントカレンダー14日目の記事です。 多少フェイクを入れているので整合性のおかしい部分があってもご了承ください。 https://qiita.com/advent-calendar/2019/yarakashi-production 背景 モバイル版だけでMAUxx万人のそこそこ規模の大きいサービス。Android/iOS/Webの3プラットフォームで提供。 開発元が撤退済みで、運営元から協力を依頼されとりあえずWeb以外の面倒を見ることに。2社にバラバラに開発を頼んでいたようで、なぜか変なところでAWS環境が2つに別れている。 色々と設計が荒く、ドキュメントもないのでアプリの追加開発の片手間でアーキテクチャの全容把握と改善計画を練っている途中の状況 新規登録時の確認メール、パスワード再発行メールでAWS SESを利用(メール利用はそれだけと認識

    [AWS] Amazon SESのアカウントが止められちゃった話 - Qiita
  • いつものように本番作業してたはずなのに - Qiita

    この記事は「番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。 https://qiita.com/advent-calendar/2019/yarakashi-production なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。 具体性が乏しい部分もあると思いますが、そこはお察しください。。。 やらかし 背景(前提条件) いっていに昔の話です ETL(データ加工)サーバ 数十を超えるシステムからデータを集める BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している 複数のチームが共存しているサーバ アプリ面では比較的疎 ETL処理のリリース前に番サーバ上で試験をする取り決めになっていた 性能や番相当データのテストが安全に行えるような環境

    いつものように本番作業してたはずなのに - Qiita
  • 本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita

    番環境でやらかしちゃった人のアドベントカレンダーです。 例) DB吹き飛ばした 番サーバをデストロイした ネットワーク設定をミスって番サーバにアクセス出来なくなり、サーバが世界から孤立した などなど... 以下の2点については必須項目なので、記述お願いします。 惨劇はなぜおこってしまったのか 二度と惨劇を起こさないためにどうしたのか もう二度とあの惨劇を繰り返さないために、みなで知見を共有しましょう。

    本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita
    paulownia
    paulownia 2019/11/17
    ひぃ
  • 6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst

    NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか? Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を

    6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst