並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 236件

新着順 人気順

fargateの検索結果41 - 80 件 / 236件

  • N予備校のインフラを Amazon EKS に移行した話 - ドワンゴ教育サービス開発者ブログ

    N予備校のインフラを Amazon EKS に移行した話 はじめまして。ドワンゴの教育事業で SRE エンジニアをしている西永です。 N予備校 では Kubernetes を採用しています。 これまでは Control Planes 含めすべての構成要素を自前で構築し運用していましたが、様々な問題が発生してきたことから Amazon EKS に移行をおこないました。 この記事では、Amazon EKS への移行に取り組んだ事例にについて紹介します。 なぜ移行したのか Kubernetes のバージョンが古い これまでの構成では Kubernetes のバージョンアップが考慮されておらず、Kubernetes を利用した N予備校の提供開始以降バージョンアップができていない状態でした。 そのためバージョン 1.7 を利用し続けていました。 バージョン 1.7 は 2017 年にリリースされ、

      N予備校のインフラを Amazon EKS に移行した話 - ドワンゴ教育サービス開発者ブログ
    • Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる

      はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム

        Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
      • [資料公開]「AWSいまどきの監視(モニタリング)事情 -CloudWatchのその先に-」というタイトルで登壇してきました #jawsfesta #jawsug | DevelopersIO

        みなさん、監視してますか!(挨拶 さる 10/7 (土) 開催されました JAWS FESTA 2023 in Kyushu、今回こちらのメイントラックにて 20 分お時間を頂いて、標題のタイトルで話してきました。 当日は目測で 40〜50 人前後は集まって頂いたかと思います。本当にありがとうございました! 何名かの方にはその後懇親会でも声をかけて頂き、登壇冥利に尽きます。 本記事ではその資料の公開と、簡単に「どんな話をしたか」を記述したいと思います。 資料 資料はこちらになります。20 分枠なのに 50 枚あるんですが、そういうものだと思って頂けますと幸いです。 以下、簡単にお話しした内容を。 内容 AWS の環視事情 「AWS の環視 (モニタリング)」と言ったら、多くの場合 CloudWatch が最初に思い浮かぶかと思います。が、それだけではない、というのがここで話した主題になりま

          [資料公開]「AWSいまどきの監視(モニタリング)事情 -CloudWatchのその先に-」というタイトルで登壇してきました #jawsfesta #jawsug | DevelopersIO
        • 「みんなの銀行」は、GCPで稼働する「Cloud SQL」を中核に「K8s」でコンテナ化されたアプリケーション群を東西リージョンで両現用化したかなり画期的なシステム構成で面白いけど、尖りすぎてる話

          (๑╹◡╹๑) @tsuchie88 みんなの銀行は、アクセンチュアがシステム構築しただけじゃなくて、GCPで稼働するCloud SQLを中核にK8sでコンテナ化されたアプリケーション群を東西リージョンで両現用化したかなり画期的なシステム構成で面白いんだけど、サービスもカードレスでスマホのみ、サブスクモデルと尖りすぎてるんだよな pic.twitter.com/4xMikwGQwf 2024-05-30 21:49:00 (๑╹◡╹๑) @tsuchie88 アクセンチュアって、海外では勘定系パッケージを販売してるし、Citibankのフロントエンドシステムとか個別構築も手掛けてたりして、何気に金融系システムベンダーとしての存在感があるんだけど、日本ではあんま強くなかっただけにMAINRIはスクラッチで日本で投入したライト勘定系で面白いんだが 2024-05-30 21:54:08

            「みんなの銀行」は、GCPで稼働する「Cloud SQL」を中核に「K8s」でコンテナ化されたアプリケーション群を東西リージョンで両現用化したかなり画期的なシステム構成で面白いけど、尖りすぎてる話
          • ecspressoを活用したECSデプロイの改善 - LayerX エンジニアブログ

            2月にバクラク事業部Platform Engineering部DevOpsチームに入社したid:itkqです。7月はLayerXエンジニアブログを活発にしよう月間 ということで、この記事では、私が入社してから中心となって進めた、ECSサービスのデプロイの改善について書いています。 バクラクのインフラ 私が所属するバクラク事業部では、バクラク請求書をはじめとする、BtoB向けのSaaSを提供しています。SaaSは主にAWS上でホストしており、サービスの大半がECS Fargateにデプロイされています。昨年、プロダクト開発をイネーブルメントするEnablingチームが発足し*1 、今後の事業成長を支えられるようなソフトウェアアーキテクチャと周辺の仕組みが発達してきています。以下の記事で述べられているように、モノレポかつサービスが多数存在します。 tech.layerx.co.jp DevOp

              ecspressoを活用したECSデプロイの改善 - LayerX エンジニアブログ
            • [ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media

              この記事について みなさん、ECS利用していますか!? AWSでコンテナを使うのなら、ECSですよね!?(kubernetesわからない勢) ECSはタスクという単位で、アプリケーションを実行させます。 そして、タスクの中にコンテナが1つ以上稼働します。 タスクはタスク定義から作成されます。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル(以後taskdef.json)として運用することが一般的です。 このtaskdef.jsonを実運用する際に迷うポイントがあります。 それは以下のどちらの方法にするかです。 – 方法① : 各環境ごとにtaskdef.jsonを用意する – 方法② : 各環境でtaskdef.jsonを共用する ①,②について、それぞれの詳細/メリット・デメリットについて洗い出しをして、どちらを採用すべきかについての見解を述べていきます。 あく

                [ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media
              • Kubernetes初学者が担当したGKE移行プロセスの全貌 - Gaudiy Tech Blog

                はじめまして。Gaudiyでエンジニアをしているあんどう(@Andoobomber)です。 クラウドネイティブ全盛の世の波に乗り、この度 Gaudiy では Cloud Run から Google Kubernetes Engine (GKE) への移行を行いました。 この記事では、その移行プロセスの全体像を共有し、得られた教訓と今後の展望を探ってみたいと思います。 1. Before After: 移行の概観 1-1. Before 1-2. After 2. なぜGKE環境に移行したのか 3. 移行のプロセス 3-1. Kubernetesを学ぶ (1週間: 2023/10/01~) 3-2. Dev on GKE環境作成 (2-3週間) 3-3. Staging on GKE環境作成 (2日) 3-4. Private Clusterへの移行 (1-2週間) 3-5. Prod on

                  Kubernetes初学者が担当したGKE移行プロセスの全貌 - Gaudiy Tech Blog
                • コスト削減成功!Amazon Auroraの監査ログをS3に保存する仕組みを構築した話 - Classi開発者ブログ

                  こんにちは。プロダクト本部Growth部でエンジニアをしている id:ruru8net です。 前回はこちらの記事を書かせていただきました。 tech.classi.jp 今日は前述したSRE留学中にやったことの中の「Amazon Auroraの監査ログをCloudWatch Logsを経由せずS3に保存する」を紹介したいと思います。 前提 前掲の記事にもある通り、弊社のAWSにかかっているコストを調査したところCloudWatch Logsの特にAmazon RDSの監査ログの保存にコストがかかっていることがわかりました。今回は弊社で最も使用しているAmazon AuroraのMySQLのみを対象として、監査ログをCloudWatch Logsを経由せずS3に保存する仕組みを作成しました。 作成した仕組み こちらのオープンソースの仕組みを参考に構築、またLambdaのソースを使いました。

                    コスト削減成功!Amazon Auroraの監査ログをS3に保存する仕組みを構築した話 - Classi開発者ブログ
                  • インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ

                    こんにちは。カミナシでソフトウェアエンジニアをしているaomanです。 私のエンジニアとしての経歴はカミナシが2社目で、前職も含めフロントエンドからバックエンドまで一通り開発はしていました。ですが、AWSなどインフラに関しては、アプリケーション開発時必要になったところを少し触ったりするくらいで、ガッツリと本格的に学んだことがありませんでした。 そんな私ですが、今回ECS Clusterの切り替え作業を先輩エンジニア監修の元一緒に行う機会をいただきました。どのようなことをしたのか、簡単にではありますがご紹介させて頂こうと思います! ざっくり概要 カミナシのサービスでは、APIサーバーの運用にAmazon ECS(on Fargate)を利用しています。また、APIサーバーコンテナの他にいくつかのコンテナが起動しています。以下がざっくりとした図になります。1つのTask定義があり、4つのコンテ

                      インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ
                    • OpenTelemetry 良い感じ - 誰かの役に立てばいいブログ

                      最初に断っておきますと、OpenTelemetry を良く知っていたり真面目に調査しようという人が読むべき内容はここにはありません。 公式ドキュメントなりをご参照ください。これは最近 OpenTelemetry を使いだした一般人の感想記事です。 さて、いけてる Web 開発者、特にバックエンド開発者の方はオブザーバビリティという言葉は聞き及んでいるかと思います。 なかでもオブザーバビリティ三種の神器と言われている(?)ログ、メトリクス、分散トレーシングをどう実装するか頭を悩ませているかもしれません。 頭を悩ませてきた、あるいは頭を悩ませている理由の一つは、これらを実装するときに特定の実装向けになりがちであったためです。 メトリクスであれば最近は Prometheus 向けに /metrics エンドポイントとして提供する実装が多いといった話です。しかしながら、 あらゆる人が Promet

                        OpenTelemetry 良い感じ - 誰かの役に立てばいいブログ
                      • 大規模Kubernetesクラスタにおけるコンテナレジストリの高速化 - Cybozu Inside Out | サイボウズエンジニアのブログ

                        こんにちは。サマーインターンシップ2023のKubernetes基盤開発コースに参加した、高橋 (TAK848) と花田 (hanapedia) です。 Necoチーム では現在コンテナレジストリの可用性を高めるため、コンテナレジストリミラーをクラスタ内にデプロイしています。 しかし、クラスタが数百台程度まで大きくなり、レジストリミラーからコンテナイメージを同時に大量にPullするようになりました。 そのため、イメージの取得に数十分もの時間がかかってしまう問題が起きました。 この問題に対処するため、Spegel というステートレスなレジストリミラーの動作検証を行い、PodのイメージのPullのタイミングを制御するカスタムコントローラー cat-gate を開発・検証しました。 その成果を紹介します。 課題 KubernetesではPodを起動する際、コンテナイメージを取得する必要があります

                          大規模Kubernetesクラスタにおけるコンテナレジストリの高速化 - Cybozu Inside Out | サイボウズエンジニアのブログ
                        • Security-JAWS DAYSに「ECS on Fargate のセキュリティ対策は何をやるべき? 開発者目線で考える」というタイトルで登壇しました #secjaws #secjawsdays | DevelopersIO

                          はじめに CX事業本部アーキテクトチームの佐藤智樹です。 今回は以下のイベント「Security-JAWS DAYS」で登壇させていただきました。 以下のSpeakerDeckで資料を公開しました。今回話しきれなかった内容として、NIST SP-800 190の中で対象外として内容の紹介やコンテナランタイムという場合の種類などについて書いたのでよければご覧ください。 登壇のモチベーション 今回の登壇ではNIST SP800-190をベースにECS on Fargateだと何をやるべきか考えてみました。これを日本中のいろんな会社で個別にやっていると時間がもったいないので、自分なりに読み解いて関連部分を切り出して対応方法を話させてもらいました。ECS on Fargateには関連ない部分と判断したものは省いたりしています。もしこの部分はこの方がよいなどあればどんどん改善していきたいので、Twi

                            Security-JAWS DAYSに「ECS on Fargate のセキュリティ対策は何をやるべき? 開発者目線で考える」というタイトルで登壇しました #secjaws #secjawsdays | DevelopersIO
                          • はてなにおけるEKSの運用と自動化 (2024年版) - Hatena Developer Blog

                            サービスプラットフォームチームで SRE を担当している id:masayosu です。 先月からですが Hatena Developer Blog にて SRE 連載を始めました。先月の記事は はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog です。 毎月はてなの SRE が交代でブログ記事を書きますのでお楽しみに。 この記事は2024年2月の SRE 連載の記事です。 はてなの EKS 利用について 私が所属するサービスプラットフォームチームでは EKS の運用を続けており、先日 Kubernetes 1.23 から 1.28 へのアップグレードを完了しました。 私のチームは少人数で形成されているのですが、担当しているサービスは大小様々あり EKS クラスター上では数十個のサービスが稼働しています。 少

                              はてなにおけるEKSの運用と自動化 (2024年版) - Hatena Developer Blog
                            • Kubernetesは怖くない!開発者のためのインフラトラブルシューティング入門

                              Kubernetesが導入される企業が徐々に増える中で、「これまでインフラレイヤに触ったことがないのにKubernetesを触る必要が出てきた」という開発者の方もいるのではないかと思います。そういった方にむけて「Kubernetesとはなにか」からはじまり、Kubernetesに乗せたアプリケーションが動かなくなって困ったときのトラブルシューティング方法を紹介するスライドです。 残念ながら資料内で動画を再生することができないためターミナル画面の画像のみになっているスライドがあります。

                                Kubernetesは怖くない!開発者のためのインフラトラブルシューティング入門
                              • AWS FargateにおけるAmazon ECS クラスターの効果的な分け方を様々な観点で考えてみた | DevelopersIO

                                はじめに AWS Fargateを使用している際に、ECSクラスターをECSサービスごとやECSタスクごとにどのように分けるかに迷うことがありました。 そこで、個人的に複数の観点からクラスターの効果的な分け方を考えてみました。 なお、この記事ではECS on EC2ではなく、ECS on Fargateのみに焦点を当てています。 ECSについて ECSの構成について簡単に説明しますと以下の3つに分かれます クラスター タスクとサービスを実行する基盤です サービス ECSクラスター内で、タスクを実行し管理します タスク タスク定義に基づいてコンテナを起動します 今回は、タスクとサービスを実行する基盤であるクラスターをどのような単位で分けるべきかを考えてみました。 一般的 一般的には、システムや環境ごとにクラスターを作成すると良いでしょう。 理由としては、2点あります。 1. リソース作成の簡

                                  AWS FargateにおけるAmazon ECS クラスターの効果的な分け方を様々な観点で考えてみた | DevelopersIO
                                • 大規模サービスのローンチに向け、パフォーマンスチューニングした話 #go #aws

                                  背景 こんにちは!Hanoi Dev Centerでバックエンドエンジニアをしているminhquangです。この記事では、私がAI事業本部のある新規プロダクト開発に参画した際に経験したパフォーマンスチューニングについて話したいと思います。 皆さんはサービスのローンチ(サービスを世の中に初めて出すリリース)をやったことがありますか。サービスローンチするときに、リクエストのスパイクや、ユーザー数の増加によるサーバー負荷増加など、様々な未知な課題が存在します。 私のチームでは数百万人の利用が見込まれるサービスにおいて、18000RPSを実現するべく負荷試験とパフォーマンスチューニングを実施しました。 本記事では、上記のサービス要件を満たすために私たちが取り組んだ負荷試験やパフォーマンスチューニングについて説明しつつ、これらの経験から得られた学びを共有したいと思います。 前提 技術スタック サーバ

                                    大規模サービスのローンチに向け、パフォーマンスチューニングした話 #go #aws
                                  • マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由

                                    https://event.cloudnativedays.jp/cnds2024/proposals/731

                                      マイクロサービス基盤にフルマネージドサービスではなくKubernetesを選択する理由
                                    • なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのか - Pepabo Tech Portal

                                      こんにちは。技術部プラットフォームグループのshibatchです。プラットフォームエンジニアとして、主にSUZURIとminneをより良くするおしごとをしています。 さて私が主として携わっているSUZURIですが、2014年のサービス開始以来、一貫してHerokuを利用してきました。このたび、10年間使っていたプラットフォームを卒業し、新たにAmazon EKS(Elastic Kubernetes Service)へ移す方針に決めた経緯についてお話しします。EKSに移すという決定にするまでに多角的に検討し、時に悩みながら決定した過程について明らかにしていきます。 なお、現在プラットフォーム移設の真っ最中であり、移設の詳細な内容はこの記事に含めません。移設作業はほぼ完了に向かっており、また別途お話しする予定です。 この記事は以下の3部構成になっています。 Herokuから移行しようと思った

                                        なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのか - Pepabo Tech Portal
                                      • [アップデート]全 AWS Fargate 利用者必見! Seekable OCI インデックスによりコンテナの起動が大幅に高速化するようになりました | DevelopersIO

                                        [アップデート]全 AWS Fargate 利用者必見! Seekable OCI インデックスによりコンテナの起動が大幅に高速化するようになりました はじめに 昨年、AWSはSeekable OCI(SOCI)の導入により、アプリケーションの起動と同時にコンテナからデータを非同期にダウンロードするコンテナイメージの遅延読み込みを実現しました。 これにより、コンテナイメージを変更せずにアプリケーションをより速く起動できるようになりました。 今回、SOCIがAWS Fargateにもサポートされました! SOCIは、ECRに保存されているコンテナイメージと同じECRにインデックスを作成しておくことで、イメージ全体をダウンロードせずに個々のファイルを抽出してコンテナを迅速に起動できます。 Amazon ECR リポジトリからイメージをダウンロードする際には、自動的にSOCI インデックスの有無

                                          [アップデート]全 AWS Fargate 利用者必見! Seekable OCI インデックスによりコンテナの起動が大幅に高速化するようになりました | DevelopersIO
                                        • 大規模サービスの負荷試験を改善していった話

                                          こんにちは!株式会社COMPASSのシステム開発部、SREチームのごーすと(@5st7)です!普段は、k8s周りの運用であったり、アプリケーションのパフォーマンスの監視、改善、インフラ周りの自動化などを積極的に進めています。三度の飯よりも好きなものがプリンで、美味しいプリンの店とかが流れてきたら1営業日以内に馳せ参じます。プリン好きな人はお店で会いましょう。 今日は負荷試験の取り組みについてご紹介できればと思います。COMPASSが提供するキュビナは現在100万人を超えるユーザーに利用していただいていますが、その分トラフィックも大きく、安定してサービスを提供できるようにするために、様々な工夫をしています。その中でも利用の集中する時間帯の負荷に耐えられるかの検証は非常に重要な取り組みの一つです。今回は、COMPASSが今まで負荷試験にどのように取り組んできたのか、その歴史と改善を行っていった

                                            大規模サービスの負荷試験を改善していった話
                                          • KubeVirtの何が嬉しいのか - inductor's blog

                                            こちらのPublickeyの記事だけ見て中身がよくわかってなさそうな人がちらほらいたので、KubeVirtを使うことの意味についてちょっと書いてみようと思う。 www.publickey1.jp ただのちっちゃなVM基盤が欲しい場合は、ほぼ不要なもの 勉強目的などを除き、仮想マシンの数が10に到底届かないような仕組みでKubeVirtを動かす場合、かなり勿体無いので採用する意味はあまりないと思う。Kubernetesを動かすことによるオーバーヘッドがかなり大きいし、正直物理的な冗長性が十分無視できるくらいの規模と言わざるを得ないので仮想化基盤としてKubeVirtを採用するメリットは薄い。EC2とかESXiとかProxmoxとか既存の仕組みを使えばいいんじゃない?と思う。 採用に値するであろうメリット1: IaaSを作りたい場合 KubeVirtの本質は、「KubernetesのAPIを使

                                              KubeVirtの何が嬉しいのか - inductor's blog
                                            • OrbStack 1.0: Fast, light, easy way to run Docker containers and Linux

                                              If you work with Docker on an M1 Mac, do yourself a favor and install orbstack.dev Every operation feels 100x faster, and it should also have a lighter impact on the battery life of M1 Macs. ⚡️🔋 Hat tip to @kandros5591 👏 OrbStack is light Are your MacBook's fans taking off into space? OrbStack also has optimizations to strike a careful balance between performance and resource usage, resulting in

                                                OrbStack 1.0: Fast, light, easy way to run Docker containers and Linux
                                              • 定量データと定性評価を用いた技術戦略の組織的実践 / Systematic implementation of technology strategies using quantitative data and qualitative evaluation

                                                CNDS2024 https://event.cloudnativedays.jp/cnds2024/

                                                  定量データと定性評価を用いた技術戦略の組織的実践 / Systematic implementation of technology strategies using quantitative data and qualitative evaluation
                                                • AWS Config が高いと感じたら。AWS Config のコストを15分の1に下げた話 - ABEJA Tech Blog

                                                  切っ掛けと問題の認識 AWS Config のカウント数の監視 対象外にしたいリソースが見つかったら AWS Config 側で除外する 実際のコスト削減効果 なぜもともとコストが高かったのか まとめ こんにちは、ABEJAの村主です。ABEJAアドベントカレンダー2023の18日目の記事です。今回は、意外にも高額になりがちなAWS Configのコスト削減について、どのように対応したかをご紹介します。特に、AWS Configのコストを大幅に減らすためのアプローチについてお話しします。また、CloudWatch で AWS Config のカウント量を可視化する方法はあまり見かけなかったのでブログにしておきました。 切っ掛けと問題の認識 最初に気づいたのは、AWS Cost Explorer を確認していたときです。そこで見たAWS Configのコストは、1日あたり約$15、月間では約

                                                    AWS Config が高いと感じたら。AWS Config のコストを15分の1に下げた話 - ABEJA Tech Blog
                                                  • [アップデート] Amazon CloudWatch でアラームに関する推奨事項が提供されるようになりました | DevelopersIO

                                                    いわさです。 Amazon CloudWatch の今朝のアップデートで、アラームの対象メトリクスとしきい値の推奨事項が提供されるようになりました。 CloudWatch Alarm を使った監視を始める時に、「どのメトリクスをどういう条件くらいでやるのが良さそうか、どの程度が一般的なのか」など、指針が欲しくなるシーンがあります。 「ワークロードごとに適切な値を設計することが必要」と言いつつも、まずは手軽に推奨事項から始めたいというケースも多いです。 今後は CloudWatch コンソールが推奨事項を提供してくれます。 「アラームに関する推奨事項」トグルボタンが追加されている CloudWatch メトリクス画面には現在稼働しているワークロードが出力したメトリクスが表示されています。 このメトリクス画面のいくつかの箇所で次のような「アラームに関する推奨事項」というトグルボタンが追加されて

                                                      [アップデート] Amazon CloudWatch でアラームに関する推奨事項が提供されるようになりました | DevelopersIO
                                                    • AWS ECS Fargateは1分間にいくつまで数えられるか-Linux/ARM64とLinux/X86_64の性能比較

                                                      AWS Graviton2 プロセッサは、64 ビットの Arm Neoverse コアを使用してアマゾンウェブサービスがカスタムビルドしたもので、Graviton2 を搭載した Fargate は、同等のインテル x86 ベースの Fargate に比べて、最大 40% の料金性能向上と 20% の低コストを実現し、

                                                        AWS ECS Fargateは1分間にいくつまで数えられるか-Linux/ARM64とLinux/X86_64の性能比較
                                                      • エンジニアは全員おうちKubernetesをやるべし【Part 2:どうやるのか】 - Qiita

                                                        こんにちは。おうちKubernetesを勧めるためにやってきました。 このシリーズでは、Part 1で「なぜやるのか」、Part 2で「どうやるのか」について話します。 この記事は自宅サーバー上のKubernetesで不特定多数向けのサービスを展開することを勧めるものではなく、自分用・身内用のアプリを自宅サーバー上のKubernetesで運用することを勧めるものです。 ハード面 1台構成 or 複数台構成 複数台構成を取るメリットは大きいものだと以下があります。 1台が不調でも残りのサーバーで処理を継続できる(可用性が高まる) 大量のアクセスを捌ける 前者は、自宅サーバーでは気にしても仕方がないというか、停電やネット回線の障害で簡単に落ちるため、過度に可用性を気にする必要はないと思います。逆に言えば、可用性を気にする場合には、そもそも自宅サーバーはあまり向いていません。電源やネットを普段使

                                                          エンジニアは全員おうちKubernetesをやるべし【Part 2:どうやるのか】 - Qiita
                                                        • EKSコンテナ移行のトラブル事例:推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog

                                                          こんにちは、モノタロウの SRE グループ・コンテナ化推進チームの田中です。 現在、私たちはシステムモダナイゼーションのプロジェクトの一環として、200以上のエンドポイントを持つモノリスのバックエンド API を EC2 上から Kubernetes マネージドサービスの EKS(Elastic Kubernetes Service)に移行しています。ノードは Fargate を使用し、監視には Datadog と Sentry を導入しています。 今回、EC2 に流れているリクエストを全て EKS に振り分けを行おうとしておりました。その際に外部(DB、 サービス)への疎通ができないといった内容の Sentry のエラーが大量に発生し、切り戻しをせざるを得ない状況に陥ったのです。エラー内容を詳しくみたところ名前解決に関するものであり、今回私たちは CoreDNS の設定を行うことで解決し

                                                            EKSコンテナ移行のトラブル事例:推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog
                                                          • Go製CLIツールGatling Commanderによる負荷試験実施の自動化 - ZOZO TECH BLOG

                                                            はじめに こんにちは、ML・データ部MLOpsブロックの岡本です。 MLOpsブロックでは機械学習モデルの実験基盤の作成、機械学習モデルを組み込んだAPI・Batchの開発・運用・保守を行なっています。APIを開発する際には負荷試験を実施し、本番環境で運用する際に求められるスループット・レイテンシを達成できるか確認します。 MLOpsブロックでの従来の負荷試験実施には人手を要する定型的な作業が複数ありました。また頻繁に行う作業でもありトイルとなっていました。 本記事ではMLOpsブロックで抱えていた負荷試験実施の課題と、解決のために開発したOSSのCLIツール、Gatling Commanderについて紹介します。Gatling Commanderが負荷試験の実施におけるトイル削減の一助になれば幸いです。 github.com 目次 はじめに 目次 背景・課題 従来の負荷試験実施の方法 分

                                                              Go製CLIツールGatling Commanderによる負荷試験実施の自動化 - ZOZO TECH BLOG
                                                            • EKSコンテナ移行のトラブル事例:ALBの設定とPodのライフサイクル管理 - MonotaRO Tech Blog

                                                              こんにちは、SREグループの岡田です。 モノタロウではモノタロウのクラウドネイティブ化の取り組みについて - MonotaRO Tech Blog にも記載されているようにシステムのモダナイズに取り組んでおり、その一環でEKSのPoCそして実際にECサイトの裏側のAPIを対象にコンテナ化に取り組みました。 この記事では移行時に起こったトラブルとハマったポイントの1事例をご紹介します。 前提 起こったトラブル トラブルシュート 1. 問題の整理と仮説 2. 検証 検証1.Podのステータスがterminate状態になってから削除されるまでの時間を変えてみる。 検証2.Pod Readiness Gateを試す。 検証3. ALBのDeregistration delay(登録解除までの待機時間)を短くしてみる。 分かった事 ALBを含めたPod入れ替え時の挙動 EKSにおけるトラブルシュート

                                                                EKSコンテナ移行のトラブル事例:ALBの設定とPodのライフサイクル管理 - MonotaRO Tech Blog
                                                              • Kubernetesに対する理解を高めてKubernetesの「わからない」を減らそう

                                                                Kubernetes Novice Tokyo #29 で発表したLT資料です イベントURL: https://k8s-novice-jp.connpass.com/event/300438/ 動画URL: https://www.youtube.com/watch?v=WZHDlB8P9_4 参考資料: https://github.com/kubernetes/kubernetes/tree/v1.28.4 https://github.com/coredns/coredns/tree/v1.11.1 https://github.com/coredns/example https://github.com/coredns/coredns/blob/v1.11.1/plugin/kubernetes/README.md https://github.com/kubernetes/dn

                                                                  Kubernetesに対する理解を高めてKubernetesの「わからない」を減らそう
                                                                • 「基礎から学ぶコンテナセキュリティ」という書籍を書きました

                                                                  # どういう書籍か コンテナの要素技術である Linux Namespaces などの Linux の機能について体験し、それらが機能していないコンテナではどういった脅威が生じ、どのような攻撃手法があるのかについて紹介した本です。 副題は「Dockerを通して理解するコンテナの攻撃例と対策」ですが、演習題材として Docker を使うという意味であり、Kubernetes などの環境では通用しないという意味ではありません。本書を通して得た知識は、Docker だけでなく、Kubernetes や Nomad などのコンテナ環境のセキュリティに適用できるように書いています。 # 他の書籍との違い コンテナとそのセキュリティに関する書籍はいくつかあります。有名どころだと次のようなものがあり、これらの中でセキュアなコンテナ運用について書かれています。 Docker/Kubernetes開発・運用

                                                                    「基礎から学ぶコンテナセキュリティ」という書籍を書きました
                                                                  • デスクトップ上にDockerコンテナ環境とKubernetes環境を構築する「Podman Desktop 1.11」リリース。Appleシリコン上でAMD64バイナリを高速に実行する「Rosetta 2」に対応

                                                                    デスクトップ上にDockerコンテナ環境とKubernetes環境を構築する「Podman Desktop 1.11」リリース。Appleシリコン上でAMD64バイナリを高速に実行する「Rosetta 2」に対応 オープンソースで開発されている、WindowsやMacのデスクトップ環境上にDockerコンテナとKubernetes環境を容易に構築できる「Podman Desktop」の最新版となる「Podman Desktop 1.11」のリリースを発表しました。 Podman Desktop v1.11 is now out! Includes Rosetta support for Apple Silicon, Improvement to @kubernetesio , increased manifest support, bug fixes, and an experimenta

                                                                      デスクトップ上にDockerコンテナ環境とKubernetes環境を構築する「Podman Desktop 1.11」リリース。Appleシリコン上でAMD64バイナリを高速に実行する「Rosetta 2」に対応
                                                                    • KubernetesのPodを事前にスケールアウトする仕組みをCronJobで実装し、ジョブの処理遅延を低減した話 - ANDPAD Tech Blog

                                                                      1. はじめに こんにちは、SWEのあかりです。 今回は、SREの角井さん(@cass7ius)と一緒に、Kubernetes(以降、K8sと表記)のPodを事前にスケールアウトする仕組みをK8sのCronJobで構築したので、その実装背景・技術選定・実装方法について実例を紹介します。 この記事を読んで得られるものは以下の3点です。 Podを事前にスケールアウトさせて、ジョブの遅延を低減した実例 技術選定時に行った定性分析の実例 Podからkubectlコマンドを実行する実装例 2. 前提の説明 掲題の実装対象は施工管理サービスであり、これは社内で最も古くから稼働しているモノリシックなRailsアプリケーションです。施工管理サービスのおおよそのインフラ・技術構成は下図の通りになっています。 施工管理サービスのインフラ構成図 上図の通り、施工管理サービスはEKSクラスター上で稼働しており、お

                                                                        KubernetesのPodを事前にスケールアウトする仕組みをCronJobで実装し、ジョブの処理遅延を低減した話 - ANDPAD Tech Blog
                                                                      • 人間によるKubernetesリソース最適化の”諦め”とそこに見るリクガメの可能性 | メルカリエンジニアリング

                                                                        Platformチームでエンジニアをしているsanposhihoです。メルカリのPlatformチームでオートスケーリング周りの課題の解決を担当しており、Kubernetes UpstreamでもSchedulingやAutoscaling周りの開発に参加しています。 メルカリでは全社的にFinOpsに取り組んでおり、Kubernetesリソースは最適化の余地があるエリアです。 メルカリではPlatformチームとサービスの開発チームで明確に責務が分かれています。Platformではサービス構築に必要な基礎的なインフラストラクチャを管理し、それらを簡単に扱うための抽象化された設定やツールなどの提供を行っています。サービスの開発チームは、それらを通してサービスごとの要件に応じたインフラストラクチャの構築を行います。 サービスやチームの数も多く、そのような状況での全社的なKubernetesリ

                                                                          人間によるKubernetesリソース最適化の”諦め”とそこに見るリクガメの可能性 | メルカリエンジニアリング
                                                                        • 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
                                                                          • NTTドコモ、全国展開する5Gの無線アクセスネットワークをAWSの「Amazon Elastic Kubernetes Service Anywhere」を用いて展開すると発表

                                                                            NTTドコモ、全国展開する5Gの無線アクセスネットワークをAWSの「Amazon Elastic Kubernetes Service Anywhere」を用いて展開すると発表 NTTドコモとAWSは、NTTドコモが日本全国で商用展開する5Gの無線アクセスネットワーク(Open RAN)を、AWSの Amazon Elastic Kubernetes Service Anywhere(以下、Amazon EKS Anywhere)を用いて展開すると発表しました。 5Gでは、これまで通信キャリアや通信機器ベンダごとに閉じていた基地局などの無線アクセスネットワーク(Radio Access Network)の仕様を、オープンな仕様にすることで、異なるベンダの機器を組み合わせて構築できるできるようにする「Open RAN」(Open Radio Access Network)が急速に進んでいます

                                                                              NTTドコモ、全国展開する5Gの無線アクセスネットワークをAWSの「Amazon Elastic Kubernetes Service Anywhere」を用いて展開すると発表
                                                                            • AWS Fargate Enables Faster Container Startup using Seekable OCI | Amazon Web Services

                                                                              AWS News Blog AWS Fargate Enables Faster Container Startup using Seekable OCI While developing with containers is becoming an increasingly popular way for deploying and scaling applications, there are still areas where improvements can be made. One of the main issues with scaling containerized applications is the long startup time, especially during scale up when newer instances need to be added.

                                                                                AWS Fargate Enables Faster Container Startup using Seekable OCI | Amazon Web Services
                                                                              • 「安全なサーバーレスアーキテクチャを設計するには(Updated 2023 Version)」を公開しました! – csajapan

                                                                                本書は、CSA本部の「How to Design a Secure Serverless Architecture Updated 2023 Version」の翻訳版で、2022年1月29日に公開した「安全なサーバーレスアーキテクチャを設計するには」のアップデート版になります。 こちらからダウンロードしてください。

                                                                                • スタディサプリにおけるKarpenterの導入トラブル振り返り - スタディサプリ Product Team Blog

                                                                                  スタディサプリにおけるKarpenterの導入トラブル振り返り こんにちは。スタディサプリ小中高SREの@aoi1です。 スタディサプリでは、Kubernetesを利用しているのですが、Nodeの運用自動化のために2023年3月から本番環境を含む全環境でKarpenterを導入しています。 Karpenterのおかげで開発者体験を向上させることができたり、コスト削減を行うことができました。便利で良いことが沢山ある一方、本番環境で問題が発生するなどいくつかハマったこともありました。 本ブログでは私たちがハマったポイントを通じて、Karpenterの導入を検討している方、あるいは既に本番環境でKarpenterを運用している方にとって参考になればと思います。 Karpenterとは KarpenterはAmazon Web Sevice(AWS)が開発しているOSSで、「Karpenter s

                                                                                    スタディサプリにおけるKarpenterの導入トラブル振り返り - スタディサプリ Product Team Blog