並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 1474件

新着順 人気順

namespaceの検索結果1 - 40 件 / 1474件

  • 【研修資料公開】低レイヤを学ぶ、Linuxカーネルとコンテナの仕組みの研修 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]

    こんにちは、羽山です。 今回はラクーンホールディングスの座学研修で私が講師を担当する 3年次 Linux && Docker研修 をご紹介します。当社は教育制度に力をいれており、入社直後に5~6ヶ月間の研修があります。そしてさらに n年次研修 という枠組みで2年次、3年次、4年次と定期的に研修を実施して、経験を積んだ各ステージに必要な知識・スキルを補完しています。 3年次 Linux && Docker研修は入社から3年目の1~2月頃(4年目目前)に実施していて、エンジニアとしての実力も付いてきた段階で受けることになります。 4年目目前ともなれば Linux や Docker を普段から開発に利用していて基本操作には困っていないはずです。 一方で Linuxカーネルの役割を聞かれたら返答に窮したり、コンテナとはプロセスと言葉では知っていても実はよく分からなかったり、そういうあたりが本研修の

      【研修資料公開】低レイヤを学ぶ、Linuxカーネルとコンテナの仕組みの研修 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
    • 5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる

      はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、

        5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
      • 4 ステップでモダンな tsconfig.json を作る - mizdra's blog

        tsconfig.json を使うと、型チェックを緩く/強くしたり、また出力する JS の形式を変えたりできる。しかしいくつかの事情から、正しく書くのが難しい。 オプションの数が非常に多い その数なんと 133 個 *1 オプションの意味や役割が理解しにくい 公式ドキュメントは丁寧にかかれているが... JavaScript や TypeScript の仕様、型の知識、歴史的経緯などを知らないと理解しづらい 推奨されるオプションが変わっていく 言語やエコシステムの進化/変化によって変わる 最近だと Node.js の TypeScript サポートで変わった 「オプションの細かい意味とかは一旦いいから、モダンで最小限の tsconfig.json がすぐに欲しい!!!」。そうした声に応えて、id:mizdra がオススメする「4 ステップでモダンな tsconfig.json を作る方法」

          4 ステップでモダンな tsconfig.json を作る - mizdra's blog
        • 「絵で見てわかるLinuxカーネルの仕組み」という本の宣伝 - 覚書

          本日10/23発売の「絵で見てわかるLinuxカーネルの仕組み」という本を自分含め6人で書きましたので、宣伝します。 絵で見てわかるLinuxカーネルの仕組み 作者:市川 正美,大岩 尚宏,島本 裕志,武内 覚,田中 隆久,丸山 翔平翔泳社Amazon 本書はIT技術のさまざまな分野について視覚的に理解するための翔泳社の「絵で見てわかる」シリーズの中の一冊です。 www.shoeisha.co.jp このシリーズは、これまでに「ITインフラの仕組み」、「Webアプリ開発の仕組み」、「マイクロサービスの仕組み」など、さまざまなものを扱ってきました。本書は「Linuxカーネル*1の仕組み」を扱います。Linuxカーネルを絵から理解するというコンセプトの本です。 Linuxカーネルは Red Hat Enterprise LinuxやUbuntuといったLinuxディストリビューションの核(カー

            「絵で見てわかるLinuxカーネルの仕組み」という本の宣伝 - 覚書
          • NATゲートウェイの通信内容を調査して対策し、コストを約60%削減した話 - ZOZO TECH BLOG

            はじめに こんにちは。WEARバックエンド部SREブロックの春日です。普段はWEARというサービスのSREとして開発・運用に携わっています。本記事では、約60%のコスト削減に成功したNATゲートウェイの通信内容の調査方法と通信量の削減方法についてご紹介します。 目次 はじめに 目次 背景 コストの把握 NATゲートウェイの通信内容の把握 CloudWatchメトリクスでの確認 VPCフローログでの確認 リゾルバーでのクエリログでの確認 調査結果をもとにNATゲートウェイ経由での通信量を削減する AWSサービスとの通信 Datadogとの通信 WEARのAPIとの通信 ECRパブリックリポジトリとの通信 結果 まとめ 背景 ZOZOではより効果的な成長を目指してコストの最適化を進めています。コストの増大はサービスの拡大を鈍化させる原因となるため、常に最適な状態に保つことが必要です。WEARで

              NATゲートウェイの通信内容を調査して対策し、コストを約60%削減した話 - ZOZO TECH BLOG
            • 【書評】マルチテナントSaaSアーキテクチャの構築 | DevelopersIO

              いわさです。 「Building Multi-Tenant SaaS Architectures」という海外の書籍があります。 著者は Tod Golding さんで、AWS のシニアプリンシパルソリューションアーキテクトの方です。 SaaS on AWS の領域でよく見かける方で、先日もラスベガスの re:Invent 2024 で講演されておりました。 マルチテナント SaaS を構築・運用するためには様々な課題に取り組む必要があるのですが、上記書籍はそれらの実用的なテクニック・戦略・パターンを解説したものです。 Building Multi-Tenant SaaS Architectures の日本語翻訳版が出るよ Building Multi-Tenant SaaS Architectures は 2024 年 4 月に発売されたのですが、来月 2025 年 1 月になんとこちらの

                【書評】マルチテナントSaaSアーキテクチャの構築 | DevelopersIO
              • 2024年末にデザインパターンについて考える - Qiita

                Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Futureアドベントカレンダーの3日目のエントリーです。昨日は@yamat2667さんのFlutterの記事でした。 デザインパターンというと、普段のプログラミングから一歩踏み込んで設計力を上げたい人が履修すべきコンテンツのように思われているようなツイートなりを見かけます。オブジェクト指向言語全般に使える知識だ、とか、開発者同士のコミュニケーションに使えるぞ、とか、コードの質が上がるぞ、とか。 一方で、パターンを詰め込もうとすると逆にコード量が増えて、パターン由来の変なクラス名が増えたりして、設計が歪むぞ、というのも当初から言われてき

                • AWS ECS Fargate Autoscaling の実戦的な基礎知識 | 外道父の匠

                  Autoscaling については過去に何度か書いているのですが、今回は ECS Fargate について少し掘り下げつつ整理してみたいと思います。 仕組みとしては難しくはなく、わりと雑な理解度でも動くっちゃ動くとはいえ、リソースとしての重要度は高い箇所であり、正しく理解するとより関連箇所の最適化が見込めるところでもあります。 概要 ECS は on EC2 で動かすと、インスタンスとタスクの二段階での Autoscaling になるところが、Fargate だとタスクのみで考えられる簡素さが強みです。 ECS Service のタスク群に対して、特定の条件(主に平均CPU使用率)を満たした時にタスク数を自動的に増減することで、負荷対策とコスト削減という目的を達成しつつ、運用者が基本は放置できることになります。 ただ、それだけの理解では浅すぎるので、増減における詳細やリスクなどについて把握

                    AWS ECS Fargate Autoscaling の実戦的な基礎知識 | 外道父の匠
                  • 監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ

                    こんにちは、新規プロダクトの開発をしています、a2 (@A2hiro_tim )です。 昨日、開発してきたプロダクトについて、正式リリースを発表させていただきました 🎉 prtimes.jp employee.kaminashi.jp さて、新規プロダクトの立ち上げは、技術選定や運用ツールの自由度が高く、どの監視ツールを使うか、選択に迷うこともあると思います。 我々のチームでは複数ツールの使用経験はあるものの、特定のツールの導入経験や深い知見があるメンバーはいなかったので、フラットに比較検討し、 Amazon CloudWatch の利用から始めてみよう、と意思決定しました。 主な選定理由は、 AWS エコシステムの中で完結できるため、Terraform Cloud などの既存の設定を流用できて新しく覚えることが少ない、AWS 上でコストを一元管理できる、等のメリットがある。 サービス開

                      監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ
                    • Node.js Now Supports TypeScript By Default

                      Matt PocockMatt is a well-regarded TypeScript expert known for his ability to demystify complex TypeScript concepts. Node 23 will soon be able to run TypeScript files without any extra configuration. Marco Ippolito, who has been driving TypeScript support in Node for the last year, landed a PR unflagging --experimental-strip-types in Node 23. Practically, this means a few things: You can create an

                        Node.js Now Supports TypeScript By Default
                      • KillerCodaで無料Kubernetesを遊び尽くす!

                        KillerCodaというサイトがあるのですが、こちらは無料でKubernetesを使えそうだったので色々試してみます! なんとCKAやCKADの練習にもなる!というのが魅力的に感じました✨ KillerCodaの概要 ユーザーが既存のシナリオから学び、クリエイターとしてはあらゆるツールや技術を教えるためのシナリオを提供できることが特徴のサイトです。単に無料で遊べるというよりは、シナリオを作る・シェアする・学ぶというところがメインのようです。 それは無料/有料ユーザーの違いにも表れています。Nodeのスペックではなく、シナリオに関連する要素が課金対象となるようです。 Free User シナリオ使用数は無限 パブリックシナリオは3つまで作成可能 PLUS Member(有料メンバー) シナリオを4時間まで使用可能 同時に3シナリオを開くことができる Exam Remote Desktopを

                          KillerCodaで無料Kubernetesを遊び尽くす!
                        • then() を export した結果www - Object.create(null)

                          Promise と Thenable Promise が ECMAScript の言語仕様に追加されたのは ES2015 ですが, Promise ライクなオブジェクトはそれ以前からも広く使われてきました (jQuery の Deferred など). そういった Promise ライクなオブジェクトとの互換性のため, Promise の仕様は本物の Promise と Promise ライクなオブジェクトを混ぜて使えるようになっています. 具体的には, Promise ライクなオブジェクトは一般に Thenable という共通のインターフェースを持つことになっています. オブジェクトが Thenable であるために必要なのは「then() という名前のメソッドを持っている」という一点のみです. もし Promise を解決 (resolve) するときに使われた値が Thenable

                            then() を export した結果www - Object.create(null)
                          • Next.js 型安全なルーティングを使う

                            Next.js 型安全なルーティングを使う Next.js では実験的な機能として、型安全なルーティングを利用できます。この機能を使うことでリンク先のパス名を静的に検査できるため、typo などのエラーを事前に防ぐことができます。 Next.js では Next.js 13.2 より実験的な機能として、型安全なルーティングを利用できます。この機能を使うことでリンク先のパス名を静的に検査できるため、typo などのエラーを事前に防ぐことができます。 なお、型安全なルーティングを利用するためには App Router と TypeScript を使用している必要があります。 型安全なルーティングの利用方法 型安全なルーティングを有効にするためには、experimental.typedRoutes フラグを有効にする必要があります。next.config.mjs に以下のように設定します。 /*

                              Next.js 型安全なルーティングを使う
                            • 第824回 Dockerコンテナをダイレクトに動かせるようになった「Incus 6.3」を、Ubuntu 24.04で試す | gihyo.jp

                              Ubuntu Weekly Recipe 第824回Dockerコンテナをダイレクトに動かせるようになった「Incus 6.3」を⁠⁠、Ubuntu 24.04で試す 世間はDocker一色と言っても過言ではない中、本連載では何度も、LXDとそのフォークであるIncusを紹介してきました。そのIncusのバージョン6.3では、Dockerコンテナを直接起動できるようになりました。今回はUbuntu 24.04 LTSに最新安定板のIncusをインストールして、Incusのシステムコンテナと、Dockerのアプリケーションコンテナを共存させる方法を紹介します。 昨今のコンテナ事情 IT業界にいると、避けては通れない技術トピックというものがいくつか存在します。Linuxやサーバーの分野では、ここ数年はやはりコンテナでしょう。 コンテナについて簡単におさらいしておくと、特定のプロセスを、ホストO

                                第824回 Dockerコンテナをダイレクトに動かせるようになった「Incus 6.3」を、Ubuntu 24.04で試す | gihyo.jp
                              • Node.jsのTypeScriptサポートについて

                                README.md Node.jsのTypeScriptサポートについて Created: 2024-07-28 Updated: https://gist.github.com/azu/ac5dafbf211ef8b5ecf386930ac75250/revisions Node.jsのTypeScriptサポートに関する議論を時系列でまとめたものです。 Start Issue: Support typescript with --experimental-strip-types · Issue #208 · nodejs/loaders SWCを使ってTypeScriptの型を削除することで、Node.jsのTypeScriptサポートを実現するという提案からスタートした。 最初の懸念としては、Node.jsのLTSは3年保守する必要があるので、依存によってNode.jsのLTSサポー

                                  Node.jsのTypeScriptサポートについて
                                • cyberagent/DeepSeek-R1-Distill-Qwen-32B-Japanese · Hugging Face

                                  DeepSeek-R1-Distill-Qwen-32B-Japanese Model Description This is a Japanese finetuned model based on deepseek-ai/DeepSeek-R1-Distill-Qwen-32B. Usage from transformers import AutoModelForCausalLM, AutoTokenizer, TextStreamer model = AutoModelForCausalLM.from_pretrained("cyberagent/DeepSeek-R1-Distill-Qwen-32B-Japanese", device_map="auto", torch_dtype="auto") tokenizer = AutoTokenizer.from_pretrained

                                    cyberagent/DeepSeek-R1-Distill-Qwen-32B-Japanese · Hugging Face
                                  • AWS 上で大規模な GitHub Actions のセルフホステッドランナーを使用する際のベストプラクティス | Amazon Web Services

                                    Amazon Web Services ブログ AWS 上で大規模な GitHub Actions のセルフホステッドランナーを使用する際のベストプラクティス 注記: お客様は自身の GitHub ランナーを管理する必要がなくなりました。AWS CodeBuild を使用すると、管理された GitHub Actions セルフホストランナーを利用できるようになり、強力なセキュリティ境界と低い起動レイテンシーを備えた一時的でスケーラブルなランナー環境を提供します。CodeBuild を使えば、独自のインフラストラクチャを維持したり、スケーリングロジックを構築する必要がありません。すべてが CodeBuild によって完全に管理されます。開始するには、単に Webhook を作成して、CodeBuild で GitHub Actions ジョブを自動的にトリガーするだけです。 概要 GitHu

                                      AWS 上で大規模な GitHub Actions のセルフホステッドランナーを使用する際のベストプラクティス | Amazon Web Services
                                    • Behind AWS S3’s Massive Scale

                                      This is a guest article by Stanislav Kozlovski, an Apache Kafka Committer. If you would like to connect with Stanislav, you can do so on Twitter and LinkedIn.AWS S3 is a service every engineer is familiar with. It’s the service that popularized the notion of cold-storage to the world of cloud. In essence - a scalable multi-tenant storage service which provides interfaces to store and retrieve obje

                                        Behind AWS S3’s Massive Scale
                                      • 「TypeScriptが当たり前」になった世界において、ESモジュール本来の運用に必要な考え方と設定とは

                                        「TypeScriptが当たり前」になった世界において、ESモジュール本来の運用に必要な考え方と設定とは こんにちは、藤吾郎(gfx)と申します。Starleyという会社でおしゃべりAIアプリ「Cotomo」を開発しています。TypeScript歴は10年くらいです。 はじめに - TypeScriptが当たり前になった世界今年(2025年)はTypeScriptがリリースされて13年、ESモジュールが導入されたES2015のリリースから10年が経ちます。今やJavaScriptプロジェクトにおいては、TypeScriptが当たり前の世界になってきました。つまり「JavaScriptプロジェクトの実装言語のデフォルトはTypeScript」という状況にかなり近づいています。 TypeScriptが当たり前の世界とは、JavaScript処理系がデフォルトでTypeScriptをサポートして

                                          「TypeScriptが当たり前」になった世界において、ESモジュール本来の運用に必要な考え方と設定とは
                                        • OpenAPI Spec を出力できる DSL、TypeSpec の実践例 - ドワンゴ教育サービス開発者ブログ

                                          この記事はドワンゴ Advent Calendar 2024の 1 日目の記事です。 はじめに こんにちは。ZEN IDの開発をしている、エンジニアのユーンです。 株式会社ドワンゴは先日2024年11月16日に開催された日本最大級のTypeScriptをテーマとした技術カンファレンス TSKaigi Kansai 2024 にプラチナスポンサーとして協賛いたしました。 ドワンゴのスポンサーブース 私は個人でセッション「型付き API リクエストを実現するいくつかの手法とその選択」を発表し、OpenAPI を中心とした手法を一例として紹介しました。 speakerdeck.com このセッションで OpenAPI を記述する手段として紹介した TypeSpec について、 ZEN ID での実践例を交えて深く取り上げます。 OpenAPI の手書きに疲れた方、また TypeSpec を使い始

                                            OpenAPI Spec を出力できる DSL、TypeSpec の実践例 - ドワンゴ教育サービス開発者ブログ
                                          • コンテナランタイムを自作した - zebian.log

                                            コンテナの仕組みを勉強したかったため、Goでコンテナランタイムを自作した。雑実装だし未実装の機能もたくさんあるが、ある程度形になってきたため現状をまとめる。 リポジトリ github.com kombu/dashi - 自作コンテナランタイム kombu/nimono - eBPFを利用したシステムコールロガー kombu/yaminabe - dashiとnimonoを利用したマルウェアサンドボックス プロジェクト名から和の雰囲気を感じるが、これはリポジトリ名をkombu(昆布)にしたかったため、せっかくなら今回は和風で固めようと思ったから。趣があっていいんじゃないでしょうか。 dashiが自作コンテナランタイムだが、nimonoとyaminabeは実験的な要素で、セキュキャン2023でコンテナを使ったマルウェアサンドボックスを実装した経験があり、今回はその再実装を自作コンテナランタイム

                                              コンテナランタイムを自作した - zebian.log
                                            • 「kubeshark」でKubernetesのトラフィックをリアルタイムに可視化する

                                              はじめに 3-shakeのSreake事業部でインターンとして活動している小林(@moz-sec)です。第13回目の今回は、KubernetesのAPIトラフィックアナライザである「kubeshark」について紹介します。 kubesharkは、KubernetesのPod、Node、Clusterを出入りするすべてのトラフィックをキャプチャし、リアルタイムで可視化するツールです。 kubesharkとは kubesharkは、WiresharkをKubernetesのためにカスタマイズしたツールです。kubesharkを使うことでトラフィックの分析が可能になり、インシデントの迅速な解決を支援します。 また、REST、GraphQL、gRPC、Redis、Kafka、RabbitMQ(AMQP)、DNSなどといった幅広いプロトコルをサポートしています。 ノード数が4台以下のクラスターであれ

                                                「kubeshark」でKubernetesのトラフィックをリアルタイムに可視化する
                                              • Laravel 11をAWS Lambdaで動くようにして簡単なAPIを作ってみる

                                                Laravel 11をAWS Lambdaで動くようにして簡単なAPIを作ってみます。 ちなみに私は割とPHP初心者です。 初心者ですが、これからAPI作成するならPHPが良いと思っています。 PHPが良い理由は、実装できる人が多いと思っていて、いざとなれば他の人(他の会社)に協力を仰ぎやすそうだからです。インターネット上に情報もいっぱいあるというアドバンテージもあると思います。 フレームワークは、PHPの中で一番ポピュラーという理由からLaravel!と考えています。 まずは、作成する環境について記載していきます。 作成する環境の構成 以下の構成で動かしてみます。 プログラム Laravel AWSリソース API Gateway Lambda 実際に、Laravel 11をAWS Lambdaで動かしてみます!! Laravel 11をAWS Lambdaで動かしてみる まずはLara

                                                  Laravel 11をAWS Lambdaで動くようにして簡単なAPIを作ってみる
                                                • TypeSpec、Orval、Storybook を使ってフロントエンドのモック生成を自動化する

                                                  はじめに フロントエンド開発において、効率的かつ一貫性のあるモック生成は非常に重要です。本記事では TypeSpec、Orval、Storybook の 3 つのツールを使用して自動生成でモックを実現する方法を紹介します。 TypeSpec は、大規模な API を提供するために Microsoft が開発し、使用している新しい API 記述言語です。 Orval は、OpenAPI 仕様から TypeScript のクライアントコードを生成するツールです。これにより、最新の API 仕様に基づいたクライアントコードを常に保持し、API との通信がスムーズに行えるようになります。 Storybook は、コンポーネントを独立して開発・テストするためのインタラクティブなツールです。コンポーネントの見た目や動作を個別に確認できるため、UI の一貫性を保ちながら効率的に開発を進めることができます

                                                    TypeSpec、Orval、Storybook を使ってフロントエンドのモック生成を自動化する
                                                  • Identity-Aware Proxy(IAP)を利用したローカル環境での開発体験の向上 - Mirrativ Tech Blog

                                                    こんにちは、バックエンドのリードエンジニア兼バックエンド基盤チームのマネージャーの夏(なつ)と申します。バックエンド基盤チームは、バックエンドエンジニアの生産性向上やコスト削減を目的に、エンジニア主導で課題を発見・解決している部署です。 今回は基盤チームが行った、Google CloudのIdentity-Aware Proxy(IAP)を利用したローカル環境での開発体験の向上について紹介したいと思います。この改善により、ローカル環境(Mac)上でも開発環境のデータを参照しながら開発が行えるようになり、開発体験が大幅に向上しました。 背景 基盤チームでは定期的にバックエンドチームのメンバーに対して「開発者体験に関するアンケート」を実施しています。基盤チームにとっての直接のユーザはバックエンドメンバーであるため、生の声を聞くことで、現在解決しようとしている問題や開発リソースの配分、優先順位が

                                                      Identity-Aware Proxy(IAP)を利用したローカル環境での開発体験の向上 - Mirrativ Tech Blog
                                                    • Amazon S3 Tables と Iceberg Tables on Amazon S3 のパフォーマンス比較 #AWSreInvent | DevelopersIO

                                                      AWS事業本部コンサルティング部の石川です。 この記事は AWS Analytics Advent Calendar 2024 の 22 日目の記事です。 Amazon S3 Tables は、「クエリパフォーマンスが最大 3 倍高速になり、1 秒あたりのトランザクション数が最大 10 倍」と言われています。本日は、「Amazon S3 Tables vs Iceberg Tables on Amazon S3 」と題して、パフォーマンスを比較したいと思います。 どのようなクエリが速くなるのか 具体的にどのようなクエリが速くなるのかについて考察します。 セルフマネージドテーブルストレージと比較すると、クエリパフォーマンスが最大 3 倍高速になり、1 秒あたりのトランザクション数が最大 10 倍になる 引用: Amazon Web Services ブログ の Amazon S3 の新しいテ

                                                        Amazon S3 Tables と Iceberg Tables on Amazon S3 のパフォーマンス比較 #AWSreInvent | DevelopersIO
                                                      • GKE/EKS(Kubernetes)のコスト可視化を良い感じにしてみた - MonotaRO Tech Blog

                                                        はじめに こんにちは!コンテナ基盤グループの楠本です。 今回はマルチテナント運用におけるKubernetesクラスタ内のコスト把握方法についてご紹介します。 見どころは EKSでKubecostを使ってみたがうまくいかなかったこと OpenCostを導入して解消したこと Datadogを使ってマルチクラウドのKubernetesを把握できるようにしたこと の3点です。 はじめに 結果:OpenCost・Datadogを使って出来たもの EKSにKubecostを試験導入してみた スプレッドシートで頑張っていた頃 EC2にかわって出番が回ってきた 過去分は取得できない EBSボリュームの管理 EBSボリュームタイプ レポート出力 インスタンスの割引率 Kubecostに躓いた コストに対するモチベーション OpenCostでリトライ 必要なものはOpenCostとPrometheus Pro

                                                          GKE/EKS(Kubernetes)のコスト可視化を良い感じにしてみた - MonotaRO Tech Blog
                                                        • @Hiroki__IT が目の前にやってきて私にIstioのこと教えてくれた。- Istio in Action の読書感想文 - じゃあ、おうちで学べる

                                                          はじめに マイクロサービスアーキテクチャの台頭により、サービスメッシュ技術は現代のクラウドネイティブ環境において外せない選択肢の一つとなっています。 その理由は明確です。マイクロサービスに求められる非機能要件の多くは類似しており、これをアプリケーション側で個別に実装すると、開発者やインフラエンジニアの負担が増大するからです。 ここで登場するのがサービスメッシュです。サービスメッシュの採用により、これらの非機能要件をインフラ層で一元管理することが可能となり、アプリケーション開発者とインフラエンジニアの責務を明確に分離できます。つまり、各エンジニアが自身の専門領域にフォーカスできるのです。これは単なる効率化ではなく、イノベーションを加速させるためサービス開発する上での労苦をなくします。 そして、サービスメッシュの世界で圧倒的な存在感を放っているのがIstioです。その包括的な機能と広範な採用で

                                                            @Hiroki__IT が目の前にやってきて私にIstioのこと教えてくれた。- Istio in Action の読書感想文 - じゃあ、おうちで学べる
                                                          • GitHub Immutable Actionsのご紹介 - APC 技術ブログ

                                                            ACS事業部亀崎です。 GitHub Universe'24 で紹介され、でもそこまで大きく取り上げられていない機能を1つご紹介します。 それが GitHub Immutable Actoinです。 https://gh.io/immutable-actions 現時点ではPublic Previewという状態です。 Immutable Actionsとは 公開されている情報も交えてご紹介しましょう。 github.com github.com みなさんご存知のように GitHub Actionは標準ではGitHub Repositoryを使って提供します。 しかし昨今のSoftware Supply Chain Securityの動向もあり、できる限り外部からなにか不正なものが紛れ込むリスクを減らしたい、そういうニーズが広がっていると思います。 そこで利用されるのがImmutable A

                                                              GitHub Immutable Actionsのご紹介 - APC 技術ブログ
                                                            • EKSでKubernetes DaemonSetを用いたロギング:Fluent-bitの運用とトラブル事例 - MonotaRO Tech Blog

                                                              モノタロウのプラットフォームエンジニアリング部門 コンテナ基盤グループの宋 明起です。 私たちは、アプリケーション開発者からコンテナシステムの認知負荷を取り除き、アプリ開発に専念できるコンテナ基盤の構築と基盤を改善し、開発者はより楽に、より安全にアプリケーションのデプロイと運用できるように支援しています。 背景 基本設計 方針 構成 サンプル モニタリング サンプル 障害 障害1. Memory overflowエラーが発生 障害2. 大量のログが欠損になっている (refresh_interval) 障害3. まだ一部ログが欠損になっている (Prestop) [FAQ] 背景 モノタロウでは以下の記事にあるようにバックエンドのAPIをコンテナ化から始め様々なレイヤーの様々なアプリケーションをEKSの上で運用しています。 EKSコンテナ移行のトラブル事例:ALBの設定とPodのライフサイ

                                                                EKSでKubernetes DaemonSetを用いたロギング:Fluent-bitの運用とトラブル事例 - MonotaRO Tech Blog
                                                              • GoでKubernetesクラスター上にモックリソースをサクッと構築するOSSを開発しました - ZOZO TECH BLOG

                                                                はじめに こんにちは。株式会社ZOZOのSRE部プラットフォームSREチームに所属しているはっちーと申します。 本記事では、Kubernetesクラスター上にモックリソースをサクッと構築する「モック構築ツール」を紹介します。ZOZOの事例をもとにした説明となりますが、Kubernetesクラスター上での負荷試験やフロントエンド開発などの効率化において広く一般的に活用できるツールのため、OSSとして公開しています。GitHubリポジトリは以下です。 github.com 本ツールは、私個人のOSSとして管理しています。ZOZOでは、社員がOSS活動しやすいように、「業務時間中に指示があって書いたソフトウェアでも著作権譲渡の許諾によって個人のものにできる」というOSSポリシーがあります。ありがたいです。 techblog.zozo.com 目次 はじめに 目次 モック構築ツールとは 開発のきっ

                                                                  GoでKubernetesクラスター上にモックリソースをサクッと構築するOSSを開発しました - ZOZO TECH BLOG
                                                                • ハンズオンで学ぶ Prometheus による Kubernetes 監視のしくみ - RAKUS Developers Blog | ラクス エンジニアブログ

                                                                  目次 はじめに Prometheusとは ハンズオン環境を構築しよう Prometheusを触ってみよう Prometheusによる監視の全体像をつかもう まとめ はじめに このブログの目的 (と、ごあいさつ) こんにちは。SREの gumamon です! 最近、Kubernetesを使う現場がどんどん増えてきました。 Kubernetesは自律的にいろいろ動いてくれる分、「今なにが起きているのか」を把握するのが意外と難しいです。 特に、構成が動的に変わるKubernetesでは、サービスディスカバリ機能のある監視ツールが欠かせません。 そんな中で、Kubernetesのメトリクス監視といえば、今やPrometheusがデファクトスタンダードです。 このブログでは、PrometheusがどのようにKubernetesの情報を集めているのかを、ハンズオン形式で体験しながら理解していきます。

                                                                    ハンズオンで学ぶ Prometheus による Kubernetes 監視のしくみ - RAKUS Developers Blog | ラクス エンジニアブログ
                                                                  • EKSでKarpenterに入学してみた 〜 Fargateを卒業する理由と方法 〜 - MonotaRO Tech Blog

                                                                    はじめに こんにちは!コンテナ基盤グループの楠本です。 前回の記事EKSコンテナ移行のトラブル事例:FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blogを投稿してから半年以上も経ちました。(時が流れるのは早い… 前回はSREグループコンテナ化推進チームとしてでしたが、今回は挨拶の通りコンテナ基盤グループとしての投稿です。 元々ECエンジニアリング部門のSREグループとして活動していましたが、今年初めに組織編成があり、プラットフォームエンジニアリング部門の1グループとして活動しています。 今回は組織とのミスマッチからEKS on FargateからEKS on EC2へ切り替えた話をご紹介します。 見どころは EKS on Fargateとプラットフォームエンジニアリングとの相性 EKS on EC2へ移行する際に検討したこと 移行して得られたこと の3点です

                                                                      EKSでKarpenterに入学してみた 〜 Fargateを卒業する理由と方法 〜 - MonotaRO Tech Blog
                                                                    • [祝] Amazon S3 Tablesが東京リージョンで利用可能になりました! #AWSreInvent | DevelopersIO

                                                                      クラウド事業本部コンサルティング部の石川です。AWS re:Invent 2024で発表された Amazon S3 Tablesが東京リージョンで利用可能になりました!記念して、現時点でどこまでできるのかを振り返ります。 なお、東京リージョンの他に、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ストックホルム)も同時に利用可能になりました。 Amazon S3 Tables とは Amazon S3 Tablesは、Apache Iceberg形式に最適化されたクラウドオブジェクトストアです。大規模な表形式データの保存を簡素化し、分析ワークロードに特化した設計によって、従来のS3と比較して大幅なパフォーマンス向上を実現します。継続的なテーブル最適化により、クエリ速度が最大3倍、トランザクション処理が最大10倍高速化されます。さらに、データ最適化やコンパクショ

                                                                        [祝] Amazon S3 Tablesが東京リージョンで利用可能になりました! #AWSreInvent | DevelopersIO
                                                                      • eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発 - Preferred Networks Research & Development

                                                                        本記事は、2024年夏季インターンシッププログラムで勤務された俵 遼太さんによる寄稿です。 こんにちは、京都大学 工学部 電気電子工学科3回生の 俵 遼太 (id:walnuts1018) です。 今回、PFN 2024 夏期国内インターンシップに参加し、社内機械学習基盤の開発・運用を行うCluster Servicesチームにて、「Podごとのインターネットトラフィック量を計測するツールの開発」というテーマに取り組みました。 この記事では、社内のKubernetesクラスタにおける課題と、Podごとのインターネットトラフィック量を計測するために作成したツールについて紹介します。 社内のKubernetesクラスタにおける課題 社内の Kubernetes クラスタでは、複数のユーザーが同じクラスタを利用して様々なワークロードを動かしています。このような構成をとることで、マシンリソースの利

                                                                          eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発 - Preferred Networks Research & Development
                                                                        • TypeScript 5.8のerasableSyntaxOnlyフラグ。enumやnamespaceが消える日が来た

                                                                          TypeScript 5.8で導入されるerasableSyntaxOnlyフラグを使うと、enumやnamespace、クラスのパラメータプロパティ、moduleキーワードなどの構文をエラーとして検出できます。これらの構文はNode.jsでTypeScriptを実行する際に非互換な構文であり、本フラグの導入によりNode.jsとTypeScriptの互換性が高まります。 本記事では、erasableSyntaxOnlyフラグの挙動と、なぜこのフラグが導入されたのかを解説します。 erasableSyntaxOnlyフラグの挙動 erasableSyntaxOnly とは、「削除可能な構文のみ」という意味です。削除可能な構文とは、Node.jsでTypeScriptを実行される際に削除される構文のことです。後ほど詳しく解説します。 erasableSyntaxOnlyフラグは、tsconf

                                                                            TypeScript 5.8のerasableSyntaxOnlyフラグ。enumやnamespaceが消える日が来た
                                                                          • 第843回 UbuntuでNVMe over TCPを試す | gihyo.jp

                                                                            去る10月にUbuntu DiscourseにてNVMe/TCPを使い仮想マシンをストレージレスでUbuntu Server 24.10をブートするというProof of Concept(PoC)デモが紹介されました。NVMe/TCPは2024年3月8日のUbuntu Weekly Topicsでも紹介されているように「iSCSIの後継」といえるものです。 このPoCについては、実際に試せるスクリプト群がGitHubのnvme-tcp-pocレポジトリ(以下、PoCレポジトリ)で公開されています。これを使えば、ネットワークの構成から仮想マシンのセットアップ、Ubuntu ServerのインストールやUEFIの設定までほとんど自動で済んでしまいます。つまり、動かしてみるだけならPoCレポジトリの案内に従えば(あまり問題に遭遇することなく)実現できます。 でも、それでは「なんとなく動いたことは

                                                                              第843回 UbuntuでNVMe over TCPを試す | gihyo.jp
                                                                            • NetworkPolicyでtrafficを制御しよう - enechain Tech Blog

                                                                              はじめに こんにちは。enechainのPlatform Engineering Deskで働いているsoma00333です。 enechainではproductのdeploy先としてGKEを採用しており、Platform Engineering DeskではKubernetes Clusterの運用業務を行っています。 enechainは「エネルギーの取引所を作る」というmissionを持っており、productも増えてきています。 Platform Engineering Deskも今後ますますsecurityに力を入れていく予定です。 前回は、Platform Engineering Deskのsecurityに関する取り組みの一例として、Pod Security Admissionを紹介しました。 ※ Pod Security Admissionの紹介 今回は、引き続きsecuri

                                                                                NetworkPolicyでtrafficを制御しよう - enechain Tech Blog
                                                                              • 自動テストの実行時間を大幅短縮!分析と最適化の実践法

                                                                                Thinkings 株式会社では、sonar ATS の開発で自動テストを導入しています。過去に CI の実行時間を大幅に削減したことで全体の実行時間は短くなりました。自動テストの速度改善は手が回っていなかったので、CI 実行時間のボトルネックになっていました。今回は自動テストの実行時間を短縮するためにどうやって分析を行ってテストコードを改善したかについて説明します。 開発環境 開発環境は次の通りです。今回はバックエンドの改善内容について説明します。 Visual Studio 2022 .NET Framework 4.6.2 C# xUnit.net 実行時間の分析方法について まずは、自動テストのボトルネックを分析する方法について説明します。前回もお話しましたが、弊社では CI/CD ツールに Jenkins を使用しています。自動テストは1日に数回実行しており、その実行結果をアップ

                                                                                  自動テストの実行時間を大幅短縮!分析と最適化の実践法
                                                                                • 1人SREが朝一ダッシュボードチェックをAIに手伝ってもらいたいのでPoCしている話

                                                                                  こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 プロダクトの規模が小さいと1人 SRE という体制は珍しくないと思います。 1人で何が辛いかというと、相談相手やレビュー相手がいないことです。ですので、最近は AI/LLM に相手をしてもらっています。 運用に使っている Lambda 関数や Terraform のコードをレビューしてみたり(※1)、エラー発生時の1次対応をお願いしてみたり(※2)しています。 ※1 プルリクしたら Bedrock にコードレビューしてもらいたい ※2 AIOps入門 AWS Bedrock で障害分析 私は毎朝のタスクとして、ダッシュボードチェックを行っています。 平日なら前日分、土日祝日なら2〜3日分のメトリクスを眺めながら、異常な挙動はないか、パフォーマンス劣化が起き

                                                                                    1人SREが朝一ダッシュボードチェックをAIに手伝ってもらいたいのでPoCしている話