並び順

ブックマーク数

期間指定

  • から
  • まで

241 - 280 件 / 3325件

新着順 人気順

メトリクスの検索結果241 - 280 件 / 3325件

  • Istioがマイクロサービスからモノリシックなアプリに変化。その背景とは

    サービスメッシュを実装するオープンソースソフトウェアIstioが最新バージョンを公開した。このリリースではこれまでのコントロールプレーンの発想を一新して、複数のプロセスが協調する形から、「istiod」というモノリシックなプロセスが制御を行う方式に変更されたことが明らかになった。 バージョンアップの概要はIstioのブログ記事にあるが、より詳細にマイクロサービスからモノリシックへの変更に関しては、Christian Posta氏によるブログ記事が参考になる。 公式サイト:Istio in 2020 - Following the Trade Winds Solo.incのField CTOであるPosta氏はRed Hatのアーキテクトというキャリアの持ち主で、2019年11月のKubeConではマイクロサービスを指向するプログラミング言語であるBallerinaのセッションを行ったことも

      Istioがマイクロサービスからモノリシックなアプリに変化。その背景とは
    • Rust初心者がRustで全文検索サーバを作ってみた - Qiita

      情報検索・検索エンジン Advent Calendar 2019 の5日目の記事です。このAdvent Calendarを作った@takuya_aさんより、お誘いいただきました。 @minoru_osuka もし余裕あれば12/5の記事お願いします! https://t.co/YIA9tIB4Gj — takuya-a (@takuya_b) December 1, 2019 ということで、仕事とは別で個人的に始めたプロジェクトについて紹介できたらと思います。 私自身はApache Solrを好んで利用しています。 ただ、最近のサーバサイドの技術の移り変わりや、新しい開発言語の登場など、取り巻く環境が変化してきています。それらの習得も踏まえ、使ったことのない開発言語を用いて軽量な全文検索サーバを作り始めるという内容です。 開発した経緯 インフラの変化 ここ数年でインフラは大きく変化しました

        Rust初心者がRustで全文検索サーバを作ってみた - Qiita
      • Kubernetes障害で泣かないための羅針盤、Observabilityを活用したトラブルシューティングフロー大公開

        ※岡本、正野、宇都宮はNTTデータ所属 Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。前回から複数回に分けて「Observability(オブザーバビリティ)」「可観測性」にフォーカスして解説しています。 Kubernetesを使っていてトラブルが発生したけど、原因究明をどう進めればいいか分からない……ということはありませんか? コンテナを利用したシステムでは、マイクロサービス化が容易なので、コンポーネントやサービスの数が従来のシステムに比べて非常に多くなります。そのため、障害が発生した場合の原因の究明も大変になります。 そこで今回は、「Observabilityでいろいろとデータが取れるのは分かったけど、何からどう見ていけばいいのか分からない」という方向けに、Kubernetesで実

          Kubernetes障害で泣かないための羅針盤、Observabilityを活用したトラブルシューティングフロー大公開
        • そのトラフィック、NATゲートウェイを通す必要ありますか?適切な経路で不要なデータ処理料金は削減しましょう | DevelopersIO

          コスト最適化のご相談をいただくなかで、NAT Gateway に不要なコストが掛かっているパターンが多くみられます。また、そのような環境に限って NAT Gateway にかなりのコストが掛かっていることを把握されていないケースも少なくありません。 今回は見落としがちな NAT Gateway で無駄なコストが発生してしまうケース、何処へのアクセスで NAT Gateway を浪費してるかを確認する方法、そしてどのような改善パターンがあるかをご紹介します。 (本記事中で記載の価格はいずれも、執筆時点の東京リージョン価格を参考にしています) 目次 よくある構成 NAT Gateway に関わる料金のおさらい NAT Gateway 料金 AWS データ転送料金 実際の料金例 何が NAT Gateway を使ってるのか見当がつかない データ通信の方向を確認 VPC フローログから NAT G

            そのトラフィック、NATゲートウェイを通す必要ありますか?適切な経路で不要なデータ処理料金は削減しましょう | DevelopersIO
          • A/Bテストのベストプラクティスと落とし穴 ~KDD2019 レポート~ - Gunosyデータ分析ブログ

            はじめに 研究開発チームの関です。古川未鈴さんの結婚、ニジマス大門果琳さんの卒業、uijinの解散とアイドル業界も激動の秋を迎えていますね。 2019年8月4日から5日間、アメリカはアラスカ州アンカレッジで開催されたデータマイニング領域のトップカンファレンスであるKDD2019にGunosyから北田と関が参加・発表してきました。 これまでに2つのレポートを公開しています。 data.gunosy.io data.gunosy.io 本レポートではTutorialとして開催された「Challenges, Best Practices and Pitfalls in Evaluating Results of Online Controlled Experiments」の内容をレポートします。 内容は現在のA/Bテストのガイドラインと言ってもいい内容で、非常に参考になるポイントが多かったです。

              A/Bテストのベストプラクティスと落とし穴 ~KDD2019 レポート~ - Gunosyデータ分析ブログ
            • 「北欧、暮らしの道具店」インフラ構成の変遷、5年間の課題と取り組み|Kurashicom Tech Blog

              こんにちは。エンジニアの佐々木です。 先日12/6、弊社イベントにてカヤックの藤原さんを交えてクラシコムのSREについてお話をさせていただきました。 当日は96名と多くの方にお申し込みいただきありがとうございました。1時間半があっという間で、時間の関係でお話できなかったことも多々ありました。改めてではありますが、記事にて当日の内容含め話せなかったこともご紹介したいと思います。 当日のテーマは「インフラ強化に向けた具体的な取り組み」と「一人に頼らないチーム体制づくりを目指して」という2つでした。 この記事では前半の「インフラ強化に向けた具体的な取り組み」について紹介します。北欧、暮らしの道具店のインフラ構成の変遷を追いつつ、その時々の課題や実際の取組みについて説明していきます。 5年前(2017年5月頃)のインフラ構成エンジニア3人で作った月間1600万PVのECサイト 「北欧、暮らしの道具

                「北欧、暮らしの道具店」インフラ構成の変遷、5年間の課題と取り組み|Kurashicom Tech Blog
              • 「いい感じに成長する」エンジニアのキャリアと学び方 - 2023年オススメPython本を添えて - Lean Baseball

                このブログおよび, 登壇・アウトプットはゴリッゴリのエンジニア, 本職はコンサル企業のマネージャーとしてクラウドエンジニアリングのコンサルをやっている者です*1. この記事は, 当ブログの名物である, Pythonのオススメ書籍(と関連する技術書)の紹介エントリーです! ※去年の記事はこちら. 本年のエントリーでは「今最もいい感じなPython本」の紹介に加えて, キャリアごとに読むべき技術書(と学び方)の選び方 この年末に読んで欲しい技術書(Python本とそれ以外) 「エンジニアのキャリア形成的に期待値の考え方大事だよ」という話 この三本立てでご紹介できればと思います. というわけで, 本年のラインナップは以下の通りです. 要約すると キャリアレベルを考える オススメ技術書籍2023 ジュニア🔰 メンバー マネジメント ボード 結び - キャリアごとの期待値 【番外編】私の推し書籍2

                  「いい感じに成長する」エンジニアのキャリアと学び方 - 2023年オススメPython本を添えて - Lean Baseball
                • ECS インフラの変遷 - クックパッド開発者ブログ

                  技術部 SRE グループの鈴木 (id:eagletmt) です。 クックパッドでは Amazon ECS をオーケストレータとして Docker を利用しています。Docker 自体は2014年末から本番環境にも導入を始めていましたが当時はまだ ECS が GA になっておらず、別のしくみを作って運用していました。2015年4月に GA となった ECS の検討と準備を始め、2016年より本格導入へと至りました。クックパッドでは当初から Hako というツールを用いて ECS を利用しており、Hako の最初のコミットは2015年9月でした。 https://github.com/eagletmt/hako/commit/7f95497505ef78491f3f68e9d648204c7c9bb5e2 当時は ECS に機能が足りずに自前で工夫していた部分も多かったのですが、ECS やそ

                    ECS インフラの変遷 - クックパッド開発者ブログ
                  • 負荷テストをサーバーレスで実現するServerless-artilleryを試してみた | DevelopersIO

                    Webシステムの負荷テストツール選定にお悩みではないでしょうか。私は悩んでいました。 今回はサーバーレスで負荷テストを実施するServerless-artilleryを紹介します。 こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社 の吉井です。 今回はサーバーレスで負荷テストを実施できる Serverless-artillery を紹介します。 Lambda 関数からテスト対象 URL に対して事前に定義した回数、期間、パターンで負荷をかけます。 テストサーバーを EC2 で起動し管理することは、それなりに手間ですし、テストが長期間になればコストも無視ができなくなります。 その点 Lambda なら実行回数分のコストなので安心感はあります。 負荷テストの実施 Serverless-artiller

                      負荷テストをサーバーレスで実現するServerless-artilleryを試してみた | DevelopersIO
                    • EC2における「管理用VPC」設置の是非について

                      こんにちは、SCSKの木澤です。 先日、VPCにおける大きなアップデートが発表されました。 Multi-VPC ENI Attachmentsaws.amazon.com EC2から複数のVPCに対してENIを接続できるようになったよ、という話です。 オンプレミスのネットワーク設計経験者であれば、この話を聞いて「管理用VPCが作れるようになったな」と感じることでしょう。 実際私自身もAWS初心者の頃は管理用のネットワークが構成できないことが気になっていました。 ですが、AWSにおいては安易に管理用VPCを設置すべきではないと考えています。 その理由を下にまとめたいと思います。 オンプレミスネットワーク設計のセオリー オンプレミスにおけるネットワーク設計経験が無い方もいらっしゃると思いますので、丁寧に解説したいと思います。 今回は下図のような一般的なWeb3層のシステムのネットワークを設計す

                        EC2における「管理用VPC」設置の是非について
                      • 「実践Redis入門」所感 ~「E.G.コンバット」の観点から語る~ | フューチャー技術ブログ

                        積読を消化しようというテーマの、読書感想文連載 の2冊目です。 導入『自分たちは、クラウドネイティブじゃなくてマネージドネイティブなんだよ…』 TIGの原木です。 最近、冒頭のような開発者の嘆きを人づてに聞く機会があり、今も脳裏に残り続けています。 昨今のITシステムにおいて、クラウドサービスは欠かせないものとなっています。しかしユーザー、そして開発者として大きな利便性を享受する裏で、クラウドサービスによって巧妙に隠蔽された裏のソフトウェアを意識する機会は減り続けているのではないでしょうか? Webサービスにおいて、RedisやMemcachedに代表されるキャッシュサーバーもそのようなソフトウェアの1つです。 キャッシュサーバーは、Webアプリケーションなどデータの読み込みや保存を効率化するために欠かせない存在ですが、同じデータストアであるRDBMSなどと比較していま一歩隠れた存在だと思

                          「実践Redis入門」所感 ~「E.G.コンバット」の観点から語る~ | フューチャー技術ブログ
                        • OKRに書ける!知っておくだけでAWSコストをすぐ削減できる26個のヒント - KAKEHASHI Tech Blog

                          AWSコストをいますぐ最適化しませんか? キャッシュフロー、ユニットエコノミクス、改善しませんか? この記事では、とにかくいますぐなんとかしたい方向けの方法を金額面で大きい傾向にあるサービスごとに26個紹介します。 以下各見出し内の💰はコスト削減度、⚡はおまけでパフォーマンス改善度を指します。 (1) 💰💰💰 CloudWatch Logs: とにかくログを出さないこと、まとめること AWS料金のうち、CloudWatch Logsが上位を占める傾向にあります。保存期間が無期限だから費用がかかる...と見せかけて、実際はログ出力自体の料金が大半です。 レガシーWebアプリケーションのログは1リクエストにつき何回も何行も出力する傾向があります。フレームワーク特有の不要なログも付いてきます。勝手に出力されるログは放置せず整理して、リクエスト単位でイベントとしてまとめましょう。 参考記事

                            OKRに書ける!知っておくだけでAWSコストをすぐ削減できる26個のヒント - KAKEHASHI Tech Blog
                          • コロナ禍でも問題なし!フルリモートIoT案件(副業)をbalenaを使って完遂しました。 - 僕のYak Shavingは終わらない

                            開発環境 <2020/09/21 9:24 追記> %s/渦/禍/g— kazuph@-12kg達成! (@kazuph) 2020年9月20日 ありがとうコロナ渦警察 <追記終わり> はてブロではお久しぶりです。 この度「フルリモートIoT案件」をbalenaを使って完遂したので、その内容を共有したいと思います。 先に書いておきますが、「技術書典9でbalena本書いたから買ってほしい」という願望により書かれた記事ですw (セルフPR) 案件内容 詳しくは書けませんが、友達のベンチャーのIoTデバイス(抽象的表現)用のゲートウェイとスマホアプリとそれをつなぐクラウド部分を担当しました。 その会社には組み込みより下のレイヤーのメンバーしかいない状態だったので、今回は組み込みより上を担当した感じです。 本来であれば、IoT案件となると、開発中の試作品の目の前でうんうんうなりながら開発すると思

                              コロナ禍でも問題なし!フルリモートIoT案件(副業)をbalenaを使って完遂しました。 - 僕のYak Shavingは終わらない
                            • Four Keysを用いた改善活動のアンチパターンと、本質的な改善のために必要な「なぜ?」 - Agile Journey

                              Agile Journeyをご覧のみなさん、はじめまして。株式会社リンクアンドモチベーションの川津(@KawatsuYusuke)です。こちらの記事では主に私たちがFour Keys メトリクスを元に、開発生産性向上を目指した活動に関する話題についてお伝えします。 と言っても、『LeanとDevOpsの科学』をはじめ、Four Keysの運用に関するトピックはすでに多く語られています。また、Four Keysは便利なメトリクスであるがゆえに、ときに「Four Keysを改善する」という手段が目的化してしまうことがあります。本稿では主にこれから開発生産性向上に取り組もうとしている方に向けて、私たちの取り組みと、体験したアンチパターンをもとに、「Four Keys改善の取り組みには "なぜ?" が大事」についてお伝えします。 私たちの開発生産性向上のはじまりと、目指すべき状態の設定 Four

                                Four Keysを用いた改善活動のアンチパターンと、本質的な改善のために必要な「なぜ?」 - Agile Journey
                              • オープンソースの安全性を高める「アルファ-オメガプロジェクト」、OpenSSFが開始。マイクロソフトとGoogleがプロジェクトリーダーに

                                オープンソースの安全性を高める「アルファ-オメガプロジェクト」、OpenSSFが開始。マイクロソフトとGoogleがプロジェクトリーダーに Linux Foundation傘下のOpen Security Software Foundation(OpenSSF)は、オープンソースソフトウェアのサプライチェーン問題を改善し安全性を高めるための大規模なプロジェクト「Alpha-Omega Project」(アルファ-オメガプロジェクト)の開始を発表しました。 マイクロソフトとGoogleはこのプロジェクトのために共同で500万ドル(1ドル115円換算で5億7500万円)を拠出し、専門家を派遣してプロジェクトをリードするなど、積極的な役割を果たしています。 In The News: OpenSSF Announces The Alpha-Omega Project to Improve Soft

                                  オープンソースの安全性を高める「アルファ-オメガプロジェクト」、OpenSSFが開始。マイクロソフトとGoogleがプロジェクトリーダーに
                                • 「悪〜いコード」を読んだので、ついでにコードメトリクスを計測してみた - Qiita

                                  はじめに 先日、「悪〜いコード」を読む機会がありました。 どんな風に悪いのか、軽くですが分析してみたので、ポエムとして投稿したいと思います。 古のコード 私は普段Ruby on Railsをメインに開発を行っているのですが、ユーザーからの質問に答えるために、普段の開発や保守しているのとは全く別のシステムのコードを読む機会がありました。 そのシステムはPHPで書かれた古いコードでした。ユーザーの質問はシンプルだったので、コードを見れば一瞬で答えは見つかるだろうと思ったのですが、とても読み難いコードだったので30分ほど頭を悩ませながら読むことになりました。 何が読み難いのか 結果、ユーザーからの質問には答えることができたのですが 「僕の30分を返してくれーーー!」と叫びたい気分です。 と愚痴ってしまいましたが、それだけでは何の進歩もないので、何が読み難かったのかを明らかにしてみたいと思います。

                                    「悪〜いコード」を読んだので、ついでにコードメトリクスを計測してみた - Qiita
                                  • [書評]「New Relic 実践入門 監視からオブザーバビリティへの変革」は可観測性を学び実践するための一冊 | DevelopersIO

                                    こんにちは、臼田です。 みなさん、よりよい運用してますか?(挨拶 今回は2021年9月15日に発売された書籍「New Relic 実践入門 監視からオブザーバビリティへの変革」の書評です。オブザーバビリティ(可観測性)について概念的にも実践的にもわかりやすい図とともに理解でき、特にNew Relicを活用して、単純な監視ではない、ビジネスに貢献するための運用の実践ができる一冊でした。 この記事ではこの書籍を読んで感じた、どんな人に向いているか、特に良かったところなどを書いていきます。 どんな人に向いているか 一言でいうと、「これからNew Relicを触る人、あるいは触り始めた人が活用できる書籍」です。「New Relic実践入門」というタイトルそのままですね。 逆に言えば、関連するオブザーバビリティについて理解を深めたい、あるいはNew Relicに限らない監視や運用の考え方を学びたいだ

                                      [書評]「New Relic 実践入門 監視からオブザーバビリティへの変革」は可観測性を学び実践するための一冊 | DevelopersIO
                                    • プロダクトマネージャーがプロダクト企画についてエンジニアと話すときに、あらかじめ書いておくとよいリスト(ラフな PRD テンプレのようなもの) - ykmc09 blog

                                      以前「プロダクト企画にエンジニアを早めに巻き込む(嫌がられずに協力を得る方法)」という記事を書きました。 ykmc09.hateblo.jp 「TL;DR : ひとことでいうと」を抜粋すると以下のような感じです。 決定事項になる前に早めに巻き込もう 巻き込むときは、 その意図や相手に期待することを伝えよう 特性を理解して、ちょっとした工夫(最初の一声はチャットなどの非同期コミュニケーションを使う、etc)をしよう この記事では、「はやめに巻き込もう」ということを中心に書きましたが、最低限こういったことを考えて書いておくと、話がよりスムーズになるよ、というものを挙げてみようと思います。 プロダクトマネージャーが用意するリスト 目的の概要(なぜそれをやる?)※もっともだいじ。これが無いとかなりキツイ。 誰のための企画?(基本はエンドユーザーになる。) その人のどういう課題を解決したい? その課

                                        プロダクトマネージャーがプロダクト企画についてエンジニアと話すときに、あらかじめ書いておくとよいリスト(ラフな PRD テンプレのようなもの) - ykmc09 blog
                                      • 「脱Oracle」の背景にある、Oracle Databaseの価値を改めて考える | フューチャー技術ブログ

                                        はじめに2019年10月15日、Amazonは自社サービスにおける実質的な”脱Oracle”を発表しました。75PBに及ぶデータを、傘下のAWSが提供するDatabase Service(AuroraやDynamoDB、Redshiftなど)へと移行したとの事。 この一報は、Amazonというグローバル規模のECの巨人、クラウド・プラットフォーマーのリーダーの一角が、大規模基幹システム領域におけるRDBMSのデファクト・スタンダードと決別したという点で、業界関係者に対して非常に大きなインパクトを残したものかと思います。 大人の色々な側面が垣間見えるものの、非常に難易度の移行PJであった事はを想像に難くありません。 “Oracleもいよいよ賞味期限を迎える” 果たしてそうなのか。ここで今一度、**”脱Oracle”とは何を脱する事なのか**、を考えてみます。 “脱Oracle”とは?第1は高

                                          「脱Oracle」の背景にある、Oracle Databaseの価値を改めて考える | フューチャー技術ブログ
                                        • Facebookが障害で止まった日、プログラマはいつもより多くのプルリクエストをマージした。解析ツール企業が明らかに

                                          Facebookが障害で止まった日、プログラマはいつもより多くのプルリクエストをマージした。解析ツール企業が明らかに Haystack社はGitHubのリポジトリを監視し、プルリクエストやマージなどをメトリクス化して分析することでプログラマの生産性やボトルネックなどを計測するサービスを提供しています。 同社は、Facebookが障害によって停止した日はいつもよりプルリクエストのマージが増加したと、ブログ「Facebook Outage Increased Developer Throughput by 32%」(Facebookの障害によりデベロッパーのスループットが32%増加した)で紹介しています。 Facebook Outage Increased Developer Throughput by 32%: https://t.co/GBlNpjpMx1 — Haystack (@use

                                            Facebookが障害で止まった日、プログラマはいつもより多くのプルリクエストをマージした。解析ツール企業が明らかに
                                          • システムの複雑性と戦う方法 - CARTA TECH BLOG

                                            こんにちは。Zucksでエンジニアをやっています@karahiyo_nです。 先日社内向けに「Zucksで働き学んだ成果に繋がるプラクティス」という発表を行いました。今回はその一部を紹介したいと思います。 発表では6年間でシステム構成がどう変わってきたのかと実際にやってきたタスクを紹介しつつ より妥当な意思決定をするために より早く価値を提供できるように システムの複雑性と戦う方法 などいくつかプラクティスを紹介しました。 今回はその中のひとつ「システムの複雑性と戦う方法」について書きたいと思います。 対象のシステム像 元の発表ではZucksのシステムを取り上げて解説したのですが、ここでは次のようなシステムをイメージしてください。 非常に高いサービスレベルが求められるシステム(例えばAmazon Compute SLA相当) 低レイテンシ、高トラフィック(で、さらに増加傾向) 機能要望は尽

                                              システムの複雑性と戦う方法 - CARTA TECH BLOG
                                            • GCPをフル活用して東京五輪の2週間で約5000万ツイートをさばいた話 - JX通信社エンジニアブログ

                                              はじめまして。JX通信社でデータアナリストをしている @nrtaking です。 弊社では、7/23〜8/8に行われた東京オリンピック、8/25〜9/5に行われた東京パラリンピックにあわせて関連した日本語ツイートを全量収集し、Twitter Japanなど各社に提供していました。 内容に関する簡単な分析についてはプレスリリースでお伝えしているので、そちらもあわせてご覧ください。 prtimes.jp 実はこのツイート収集システムは、2週間ほどでほぼゼロから立ち上げたものでした。 今回は五輪関連のツイート収集を支えた技術について紹介します。 叶えたかった要件 五輪に関するツイートを、NTTデータの提供するAPIからストリームで受け取り続ける ツイート量などの統計情報やRTが多いツイート情報をダッシュボードの形で見ることができる 上記を(ほぼ)リアルタイムで実現できる 実はこの取り組みにあたり

                                                GCPをフル活用して東京五輪の2週間で約5000万ツイートをさばいた話 - JX通信社エンジニアブログ
                                              • ECSとGoで構築したシステムにDatadogを導入する | おそらくはそれさえも平凡な日々

                                                追記: GoのアプリケーションをOpenMetricsを使ってObservableにする方法については別エントリを書きました。 → https://songmu.jp/riji/entry/2020-05-18-go-openmetrics.html ECSとGoで運用しているシステムに対するDatadogの日本語知見があまり無さそうだったので書いてみる。ちなみに以下の環境です。 ECS on EC2 (not Fargate) アプリケーションコンテナのネットワークモードはbridgeモード 動的ポートマッピングも利用 背景として3月にNature Remoのインフラアーキテクチャ改善をしていて、その前にもうちょっと監視を整えたほうが良いな、ということでDatadogを導入したのがある。テストがないとリファクタリングできないように、監視がないとアーキテクチャのアップデートもやりづらいとい

                                                  ECSとGoで構築したシステムにDatadogを導入する | おそらくはそれさえも平凡な日々
                                                • AWS VPC のネットワーク小話~Public/PrivateとIPv4/6~ | 外道父の匠

                                                  日々何気なくお世話になっている VPC 含むネットワークは、ちゃんと理解しようとすると思ったより多い情報量と、それに対するパターンの経験が必要になります。 私自身、正直ネットワークのお話は好きじゃないのですが、現行の事情を踏まえてこの辺の基本と雑学を振り返っておくと、技術力のベースが整ってよろしいのではと思って整理することにしました。 はじめに 新年度なので、学習教材シリーズです。今回はネットワーク周りで、基礎に味付けするような内容です。もしかしたらお嫌いなジャンルでしょうか、でも少しだけやりましょうそうしましょう。 関連情報としては、このあたり。 公式 ENOG81: AWSのIPv6とPublic IPv4のおはなし – Speaker Deck Amazon VPC とは? – Amazon Virtual Private Cloud 外道父の匠 AWS VPCルーティングの基本から

                                                    AWS VPC のネットワーク小話~Public/PrivateとIPv4/6~ | 外道父の匠
                                                  • 社内版 Rails アップグレードガイドを公開します - Timee Product Team Blog

                                                    こちらはTimee Advent Calendar 2023 シリーズ1の25日目の記事になります。 昨日は @tomoyuki_HAYAKAWA による Swift Concurrency AsyncStreamを使ってみる #Swift - Qiita でした。 タイミーでバックエンドエンジニアをしている id:euglena1215 です。 メリークリスマス🎄 みなさんの手元にはプレゼントは届いているでしょうか。 Ruby の世界では Ruby コミッターサンタさんがクリスマスプレゼントとして新しい Ruby バージョンをリリースしてくれます。 今年は Ruby 3.3 ですね。個人的には 3.3 の YJIT がどれだけ速くなるのか楽しみです。 また、新しいバージョンのリリースにはアップグレードがつきものです。アップグレードせずには新しいバージョンの恩恵を受けることはできません。

                                                      社内版 Rails アップグレードガイドを公開します - Timee Product Team Blog
                                                    • マイクロソフト、フルマネージドな負荷テストサービス「Azure Load Testing」正式サービスとして提供開始

                                                      マイクロソフトはクラウド上で大規模な負荷テストを行えるフルマネージドな負荷テストサービス「Azure Load Testing」を正式サービスとして提供開始したことを明らかにしました。 外部に公開する予定のあるクラウドサービスでは、想定するユーザー数に対して適切なコンピューティングリソースが割り当てられているか、挙動に問題はないか、性能上の問題がある場合にはボトルネックがどこにあるか、などを本番開始前に調査する必要があります。 そのためには、あたかも実際に多数のユーザーがアクセスしてくるのと同じような状況を作り出さなくてはなりません。 Azure Load Testingは、そうした負荷の作成を作り出し、容易にテストできるようにしたものです。 上記の図にあるように、Azure Load TestingはApache JMeterのスクリプトを実行することで負荷を作り出し、それをエンドポイン

                                                        マイクロソフト、フルマネージドな負荷テストサービス「Azure Load Testing」正式サービスとして提供開始
                                                      • チームトポロジーを読んだ感想

                                                        はじめに 最近、チームってどんな構成にするのがいいんだろうか?と考えたことがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか? チーム間のコミュニケーション(インタラクション)をどう設計するか? 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか? チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、1つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく

                                                          チームトポロジーを読んだ感想
                                                        • Ruby 3.2.0 リリース

                                                          Posted by naruse on 25 Dec 2022 Ruby 3.2.0 が公開されました。Ruby 3.2では多くの機能を追加するとともに、様々な改善が行われています。 WASIベースのWebAssemblyサポート WASIベースのWebAssemblyへのコンパイルがサポートされました。これにより、ブラウザやサーバーレスエッジ環境、その他のWebAssembly/WASI環境でCRubyのバイナリが利用できるようになります。現在この移植版はThread API以外のbasic testとbootstrap testをパスしています。 Background もともとWebAssembly (Wasm)が導入されたのは、プログラムをブラウザの上で安全かつ高速に実行するためでした。しかし、様々な環境で安全かつ効率的にプログラムを実行するという目的は、Webだけでなく一般的なアプ

                                                          • Amazon VPC と接続可能なおうち Amazon ECS Anywhere クラスターの構築 | Amazon Web Services

                                                            Amazon Web Services ブログ Amazon VPC と接続可能なおうち Amazon ECS Anywhere クラスターの構築 この記事は Building an Amazon ECS Anywhere home lab with Amazon VPC network connectivity を翻訳したものです。 2014 年以降 Amazon Elastic Container Service (Amazon ECS) は AWS のお客様がコンテナ化されたアプリケーションのデプロイをさまざまなコンピュート環境へわたってオーケストレーションできるように支援してきました。これまでの Amazon ECS は Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、AWS Fargate、AWS Wavelength、AWS O

                                                              Amazon VPC と接続可能なおうち Amazon ECS Anywhere クラスターの構築 | Amazon Web Services
                                                            • フロントエンドで収集するべきテレメトリは何か

                                                              先日『フロントエンド監視の全体像と実現方法』という記事を投稿しましたが、その中でテレメトリについては触れませんでした(※本記事は上記記事の内容を知らなくても読み進められるようになっています)。 というのは、テレメトリは可観測性を実現するための重要な概念ではあるものの、テレメトリを軸に監視を考えるのは手段の目的化になってしまうと考えているからです。 重要なのはサービスにとって何を観測するべきかを考えることであり、テレメトリはそれを設計や実装に落とし込む際に現れるものです。 一方で監視に対する理解を深める上では、テレメトリを軸に考えることも重要でしょう。 そこで本記事ではフロントエンド監視においてどのようなテレメトリを収集するべきか述べていきます。 監視 SaaS と OpenTelemetry (OTel) Datadog, New Relic, Sentry のいずれかを利用することを考え

                                                                フロントエンドで収集するべきテレメトリは何か
                                                              • 入門 継続的デリバリー

                                                                継続的デリバリーとは、コード変更を必要に応じて迅速かつ安全に、継続的にリリースできるようにするための開発手法です。本書は、初めて継続的デリバリーに取り組む読者向けに、必要な知識とベストプラクティスをていねいに紹介する入門書です。基本的な概念や技術、アプローチの解説はもとより、章ごとに事例を使用しながら、継続的デリバリーを実践する際に直面するさまざまなシナリオを取り上げ、その全体像・世界観を包括的に理解することができます。 序文 はじめに 第1部 継続的デリバリーとは 1章 『入門 継続的デリバリー』へようこそ 1.1 継続的デリバリーは必要? 1.2 なぜ継続的デリバリー? 1.3 継続的デリバリーとは 1.4 インテグレーション 1.5 継続的インテグレーション 1.6 何をデリバリーするのか? 1.7 デリバリー 1.8 継続的デリバリーと継続的デプロイメント 1.9 継続的デリバリー

                                                                  入門 継続的デリバリー
                                                                • [新機能] S3 の利用状況が一目瞭然!しかも無料!「Amazon S3 Storage Lens」がリリースされました! | DevelopersIO

                                                                  本日のアップデートで Amazon S3 Storage Lens がリリースされました。 Amazon S3 Storage Lens delivers organization-wide visibility into object storage usage and activity trends S3 Storage Lens とは S3 Storage Lens はオブジェクトストレージの使用状況とアクティビティの傾向を可視化し、コスト効率化、データ保護に関するベストプラクティスに向けた推奨事項が提供されます。また AWS Organizations と連携することで AWS Organizations 内のアカウント全体のストレージ使用状況、アクティビティを単一ビューで管理できます。 無料でも使える! 標準メトリクスのみの場合、S3 Storage Lens は無料で利用できま

                                                                    [新機能] S3 の利用状況が一目瞭然!しかも無料!「Amazon S3 Storage Lens」がリリースされました! | DevelopersIO
                                                                  • Postfixのログ監視で注意すべきSMTPのステータス仕様について - Hatena Developer Blog

                                                                    システムプラットフォームチーム SREのid:MysticDollです。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の5月号です。先月分は id:heleeen さんの Mackerel で行った障害対応演習を紹介します でした。 先月 Platform Engineering Meetup #8 にて 「はてなにおけるメール基盤とDMARC対応」というタイトルで登壇させて頂きました。 speakerdeck.com この記事では資料では紹介しきれなかった、メール送信基盤の監視で気をつけるべきSMTPのステータスの仕様とそれらを踏まえた監視方法について紹介します。 メールのステータス形式 SMTP Reply Code 1桁目 2桁目 3桁目 DSN 1つ目 2つ目 3つ目 Postfixのログからのエラーのメトリクス化 まとめ メールのステータス形式 SMTPにお

                                                                      Postfixのログ監視で注意すべきSMTPのステータス仕様について - Hatena Developer Blog
                                                                    • ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG

                                                                      こんにちは、SRE部MA基盤チームの谷口(case-k)です。私達のチームでは、データ連携基盤の開発・運用をしています。 データ基盤には大きく分けて2種類あり、日次でデータ連携してるものとリアルタイムにデータ連携しているものがあります。本記事ではリアルタイムデータ連携基盤についてご紹介します。 既存のデータ連携基盤の紹介 リアルタイムデータ連携基盤の紹介 なぜ必要なのか 活用事例の紹介 データ連携の仕組みと課題 リプレイス後のリアルタイムデータ連携基盤 SQL Serverの差分データの取り方を検討 アーキテクチャ概要と処理の流れ Fluentdのプラグインを使った差分データの取得 Dataflowでメッセージの重複を排除 Dataflowで動的にBigQueryの各テーブルに出力 Pub/Subのメッセージ管理 イベントログ収集基盤 個人情報の取り扱い ビルド・デプロイ戦略 監視 データ

                                                                        ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG
                                                                      • スクラムを導入してチーム状態を可視化し持続可能なチームを目指す - ZOZO TECH BLOG

                                                                        こんにちは、計測プラットフォーム開発本部システム部SREブロックの市橋です。2021年4月に新たに発足したチームで未経験ながらリーダーを任され、気づけば約2年が経過していました。これまでを振り返ってみると、まっさらな状態から安定したチームができてきたと感じています。今回は新米リーダーとして試行錯誤する中で、チーム状態を可視化して健全なチーム運営を目指した話を紹介します。 チーム状態の可視化を考えたきっかけ リーダーを任された当初、チーム運営上の課題が色々あるのは認識していましたが、どこから手をつけるべきかが自分の中で判然としませんでした。メンバーの時に一個人として感じていた課題も、チーム全体を俯瞰して見た時にどれから優先的に取り組むべきか自信を持って判断できませんでした。まるで大海原のど真ん中にいきなり放り出された感覚でした。 そんな悩みを抱えていた時、全社に導入されているWevoxのアン

                                                                          スクラムを導入してチーム状態を可視化し持続可能なチームを目指す - ZOZO TECH BLOG
                                                                        • ISUCON12で優勝しました(チーム NaruseJun)

                                                                          8月27日に開催されたISUCON12 本選にチームNaruseJunとして参加し、スコア341,258点で優勝しました。(ISUCON12 本選の結果発表と全チームのスコア) メンバーは @sekai と @takashi_trap でした。 この記事はその参加記です。 チームについて このメンバーでのISUCONへの参加は10(予選敗退), 11(準優勝)から3回連続です。 それぞれのISUCON参加回数は @to-hutohu, @sekaiが6回目、@takashi_trapが5回目です。 予選準備 7月9日と7月17日に予選のために集まって作戦会議をしました。 7/9 1時間程度集まって素振りに向けた作戦会議 素振りの環境準備、チートシート、初動のAnsible整備、Goを思い出すなどがそれぞれ宿題として持ち帰ることに 7/17 素振り会(ISUCON11予選) 5時間くらいで初

                                                                            ISUCON12で優勝しました(チーム NaruseJun)
                                                                          • 物流支援サービスを支えるAWSサーバーレスアーキテクチャ戦略 - ZOZO TECH BLOG

                                                                            はじめに こんにちは。SRE部BtoBチームの蔭山です。Fulfillment by ZOZO(以下FBZ)で提供しているAPIシステムの運用及び監視を担当しております。 FBZではAWS Lambdaを主軸としてAWSが提供しているフルマネージドサービスのみを利用するサーバーレスアーキテクチャを採用し、構築・運用してきました。今回は実際にどのようにサーバーレスアーキテクチャを活用してサービスを構築・運用・監視しているかご紹介します。 これからサーバーレスアーキテクチャを活用してサービスを構築されようとしている方の参考になれば幸いです。 なぜサーバーレスを採用したのか FBZはZOZOTOWNとブランド様が運営されている自社ECサイト間でリアルタイムに在庫情報を連携し、ZOZOTOWNと自社ECサイトでの在庫の一元管理を実現するAPIサービスです。そのため、マスタであるZOZOTOWNの在

                                                                              物流支援サービスを支えるAWSサーバーレスアーキテクチャ戦略 - ZOZO TECH BLOG
                                                                            • YJITの性能を最大限引き出す方法 - k0kubun's blog

                                                                              RubyのJITコンパイラYJITを開発している弊社Shopifyでは、社内で最もトラフィックが多いストアフロントのアプリにRuby 3.3 (master) をデプロイして平均レスポンスタイムが16%高速化、社内で最も大きなアプリであるモノリスにRuby 3.2をデプロイして平均レスポンスタイムが9%高速化している。他の会社でも、YJITを本番で有効にしたら高速化したという事例をちらほら目にした。 一方で必ずしも良い報告ばかりではなく、YJITを有効化したらメモリを使い切ってしまったりだとか、遅くなったみたいな報告も目に入ることがある。こういった問題は我々も多かれ少なかれ経験しており、それぞれ適切に対処することで解決できたため、その知見を共有する。*1 メモリを使い切ってしまった時 zenn.dev YJITを有効化すると、YJITが生成する機械語に加えて、それに関するメタデータもメモリ

                                                                                YJITの性能を最大限引き出す方法 - k0kubun's blog
                                                                              • クラウドネイティブなデータ可視化ツール「Grafana」で、なぜかWebAssembly化したDoomがプレイ可能に。開発元が社内ハッカソンで実現

                                                                                クラウドネイティブなデータ可視化ツール「Grafana」で、なぜかWebAssembly化したDoomがプレイ可能に。開発元が社内ハッカソンで実現 クラウド上で実行される多様なソフトウェアのログやメトリクスを受け取り、運用管理のためのダッシュボード上で可視化するツールとして定番のソフトウェアが「Grafana」です。 このGrafanaの開発元であるGrafana Labsは、Grafanaのダッシュボード画面上で一人称ゲームの古典とも言えるDoomをプレイ可能にするソフトウェア「Grafana Doom」をオープンソースで公開しました。 Can it run Doom? To mark the 25th DOOMiversary of #Doom64, you can now play Doom on Grafana thanks to time series panels and th

                                                                                  クラウドネイティブなデータ可視化ツール「Grafana」で、なぜかWebAssembly化したDoomがプレイ可能に。開発元が社内ハッカソンで実現
                                                                                • 「プロダクト間共通の React コンポーネントライブラリ」がどうなったか、という話 - SmartHR Tech Blog

                                                                                  こんにちは! フロントエンドエンジニアの @diescake です! 1 年程前に @nabeliwo よりこんな記事を公開しています。 tech.smarthr.jp 一言で要約してしまうと、SmartHR の各種プロダクトで一貫したユーザー体験を提供するために、SmartHR UI という React コンポーネントライブラリを実装し始めたよ! しかも OSS として公開してるよ! という話でございました。 github.com 本記事では、それから 1 年弱たった今 SmartHR UI がどうなっているか、という話をしつつ、現在の SmartHR UI の運用・開発体制について話をしてみようと思います。 SmartHR UI は成長しているよ! 2019/08/01 2020/05/21 バージョン v3.9.2 v8.2.0 コンポーネント数1 30 66 ソースコード規模2 3

                                                                                    「プロダクト間共通の React コンポーネントライブラリ」がどうなったか、という話 - SmartHR Tech Blog