並び順

ブックマーク数

期間指定

  • から
  • まで

441 - 480 件 / 2120件

新着順 人気順

fargateの検索結果441 - 480 件 / 2120件

  • インボイス管理サービス「Bill One」の認証を内製認証基盤に置き換えて認証基盤のコストを削減した話 - Sansan Tech Blog

    Bill One Engineering Unit 共通認証基盤チームの樋口です。 Bill Oneでは昨年までAuth0を認証基盤として利用してきましたが、認証基盤を内製化することでコストを大幅に削減しました。 この認証基盤は、昨年12月に無事リリースされ、Bill Oneの認証を支えています。 今回は認証基盤の内製化に至った経緯と設計、移行プロセスについて紹介します。 Bill Oneについて 認証基盤に関する課題 解決方法の検討 IDaaS(Identity as a Service)について 設計とシステム構成について 認証基盤の設計 システム構成 アカウントの移行について メールアドレス・パスワードでのログインを利用しているユーザーの移行 SSO(Single Sign-On)の移行 振り返りと今後 ドメイン変更による問い合わせの増加 内製化によって体験の改善がスムーズに Bil

      インボイス管理サービス「Bill One」の認証を内製認証基盤に置き換えて認証基盤のコストを削減した話 - Sansan Tech Blog
    • AWS Copilot CLI を使用した永続性を持つ AWS App Runner サービスの継続的ワークフローの実現 | Amazon Web Services

      Amazon Web Services ブログ AWS Copilot CLI を使用した永続性を持つ AWS App Runner サービスの継続的ワークフローの実現 この記事は Enabling continuous workflows for AWS App Runner service with persistency using AWS Copilot CLI を翻訳したものです。 AWS は最近、AWS App Runner と呼ばれる新しいサービスを開始しました。これは、コンテナ化されたステートレスな Web アプリケーションを AWS でビルドして実行する最も簡単な方法です。App Runner は、ビルドパイプライン、ロードバランサー、スケールインとスケールアウト、そしてもちろんその基盤となるインフラストラクチャなど、コンテナを実行するために必要なすべてのリソースをプロビ

        AWS Copilot CLI を使用した永続性を持つ AWS App Runner サービスの継続的ワークフローの実現 | Amazon Web Services
      • JAWS DAYSで150人に聞いた!AWSのセキュリティ課題ランキング - Flatt Security Blog

        こんにちは。Flatt Securityの@toyojuniです。 "エンジニアの背中を預かる" をミッションに、日々プロダクト開発組織のセキュリティを意思決定から技術提供までサポートするべく奮闘しています。 さて、Flatt Securityはこの度3月2日(土)に池袋サンシャインシティにて開催されたJAWS DAYS 2024にPlatinum Supporterとして協賛し、ブースを出展させていただきました! このイベントは日本全国に60以上の支部をもつAWSのユーザーグループ「JAWS-UG」が主催するもので、参加は有料でありながら1000人以上が参加者として登録している非常に大規模なものです。当日も大盛況でした! 日々AWSを用いてプロダクト開発・運用に向き合う皆様と直接お話しする機会は、我々にとって貴重なものでした。当日ブースにお越しいただいた皆様、ありがとうございました! 「

          JAWS DAYSで150人に聞いた!AWSのセキュリティ課題ランキング - Flatt Security Blog
        • 「アラート対応で疲弊してるチームが今できること」というタイトルでAKIBA.AWS ONLINE #04に登壇しました #AKIBAAWS | DevelopersIO

          オペレーション部 加藤です。 今日は以下のイベントで登壇させていただきました。 【6/25(金)リモート開催】AKIBA.AWS ONLINE #04 – こんなときどうする⁉︎ トラブル・インシデント対応 編- #AKIBAAWS 監視運用の嫌なことあるあるを解消する、AWSの便利なツールのご紹介です。 発表タイトル「今できること」の通り複雑な設定が必要なツールはないので、もし気になるものがあればちょっとだけ触ってみてください。 資料 概要 監視運用4つのあるあるを解消できそうなAWSのツールを紹介させていただきました。 毎晩プロセス再起動のために起こされるマン 月末絶対来るけど静観するアラート なんとなくしきい値低めのWarning 対応する必要があるかどうかわからないアラート 過去の経験から、私は監視・インシデント対応には「自動化」と 「脱オオカミ少年」が必要と考えています。 インシ

            「アラート対応で疲弊してるチームが今できること」というタイトルでAKIBA.AWS ONLINE #04に登壇しました #AKIBAAWS | DevelopersIO
          • RailsアプリのフロントエンドをじわじわとNext.jsにリプレースした話と、その振り返り - High Link テックブログ

            株式会社High LinkのCTOをやっている nogaken (@nogaken1107)です。 最近はChatGPTなどのLLM系のアプリケーションを触って楽しんでいます。 ハイリンクでは「カラリア 香りの定期便」などのサービスを開発しています。 「カラリア 香りの定期便」は2021年まで、フレームワークとしてはRuby on Rails (以下Rails)単体で書かれていましたが、デザインリニューアルと合わせて2021年前半から1年間強の時間をかけてフロントエンドをNext.jsにリプレースしました。 結果として開発体験が向上し、気軽に実装できるデザインの幅が広がり、エンジニアの採用面でもメリットが得られました。 この記事では、カラリアのフロントエンドリプレースの背景、技術選定、リプレースのフロー、課題と、リプレース全体の振り返りについて紹介します。 現在、RailsでWebアプリケ

              RailsアプリのフロントエンドをじわじわとNext.jsにリプレースした話と、その振り返り - High Link テックブログ
            • AWS CDKでECS Fargate Bastionを一撃で作ってみた | DevelopersIO

              EC2インスタンスの踏み台を用意したくない こんにちは、のんピ(@non____97)です。 皆さんはEC2インスタンスの踏み台を用意したくないと思ったことはありますか? 私はあります。 VPC上のRDS DBインスタンスやRedisクラスター、OpenSearch Service ドメインなどのリソースに接続したい場合、Site-to-Site VPNやClient VPN、Direct Connectがなければ踏み台(Bastion)が必要になります。 踏み台へのアクセス方法は以下のようなものがあります。 直接SSH SSMセッションマネージャー EC2 Instance Connect そして、踏み台となるリソースとして採用される多くがEC2インスタンスだと考えます。EC2インスタンスの場合、OS周りの面倒をみる必要があります。OS内のパッケージのアップデートが面倒であれば「踏み台が

                AWS CDKでECS Fargate Bastionを一撃で作ってみた | DevelopersIO
              • Capacity Providerとは?ECSの次世代スケーリング戦略を解説する #reinvent #cmregrowth | Developers.IO

                ECSのスケーリング戦略を柔軟に設定でき、さらにFargate Spotを活用できるCapacity Provider、皆さんすでにお使いでしょうか? re:Invent2019の開催中に突如発表された新機能なのですが、「Fargate Spotとかいうのが使えるらしいで!」というキャッチーな側面はありつつも、その概念はECS全体を包括するもので、正直自分も最初とっかかりが難しかったです。 この記事は、CM re:Growth 2019 TOKYOで発表した内容を元に、Capacity Providerの全体像を掴んでもらうことを目的に書きました。ECSにおけるかなり大きな機能拡張なので、普段からECSを使われている方は、是非この記事でこの新機能を掴んでもらえればと思います。 (祭) ∧ ∧ Y  ( ゚Д゚) Φ[_ソ__y_l〉     Capacity Provider マツリダワ

                  Capacity Providerとは?ECSの次世代スケーリング戦略を解説する #reinvent #cmregrowth | Developers.IO
                • Autifyに入社します|hgsgtk

                  本日が最終出社日でした。4年3ヶ月、BASEならびにBASE BANKに在籍し、さまざまなチャレンジの機会をいただきました。 一片の悔いのない時間でした、本当にありがとうございました。 pic.twitter.com/4B6Ae2OC0b — Kazuki Higashiguchi (@hgsgtk) December 3, 2021 そして、2022年1月1日よりAutify社に入社いたします。執筆時点(2021年12月22日)では入社前ですが、ありがたいことに「次はどうされるんですか?」とお誘いを頂く機会が何度かあり、先行して公開情報にしておこうかなと思い、筆を執っています。 (The English edition is available on Medium.) これまでやってきたことBASEは正式な社会人になってから2社目です。BASEとは、ネットショップ作成サービス「BASE」

                    Autifyに入社します|hgsgtk
                  • AWS Fargate、Amazon ECSの起動と停止を自動化できる無料ツールを紹介します | DevelopersIO

                    はじめに 弊社が提供する無料のAWS運用かんたん自動化ツール「opswitch」を使って、夜間や土日祝日などの使わない時間帯に開発環境のAWS Fargate、Amazon ECSを停止させる方法を紹介します。プログラムなどの知識はなくても、Webの操作だけで設定を行えます。Fargateを例に説明をすすめます。ECS(ECS on EC2)の場合は「タスクの作成」が少し違いますので補足をご覧ください。 準備 ユーザーガイド opswitchを開始するを参考に以下の初期設定を完了させてください。 opswitchのアカウント作成 opswitchアカウントの初期設定 ユーザー属性情報登録 組織作成 AWSアカウント連携作成 タスクの作成 それではFargateを起動させるタスクから作成します。 Management Consoleでタスク数を変更したいECSサービスにタグをつけます。どのサ

                      AWS Fargate、Amazon ECSの起動と停止を自動化できる無料ツールを紹介します | DevelopersIO
                    • 数千万ユーザーのビッグデータに機械学習モデルを適用するには(広告配信ソリューション実現の工夫紹介)

                      ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。Yahoo!広告にてデータアナリストをしている國吉です。 ヤフーでは、「Yahoo!広告」という広告出稿サービスを提供しており、それに付随して、広告を出稿するクライアントを支援するためのソリューションを提供しています。本記事では、私が開発に携わっている「Yahoo! JAPAN 予測ファネル」(以下、予測ファネル)という広告配信ソリューションについてご紹介します。予測ファネルを開発するにあたっては、ビッグデータを用いて機械学習モデルの作成と推論をするため以下の課題がありました。 学習時のメモリリソースの確保、推論時間の短縮が必要 ソリューションのリリース後には数多くのモデルが作成されモデルの管理が煩雑になる 本記事では

                        数千万ユーザーのビッグデータに機械学習モデルを適用するには(広告配信ソリューション実現の工夫紹介)
                      • Laravel on ECSでのバッチ実行基盤事例|Kurashicom Tech Blog

                        こんにちは。エンジニアの佐々木です。 最近、映画アルゴの主人公のような密度が濃く整った髭を目指し日々手入れを行っています。 さて。以前、社内勉強会で発表した「北欧、暮らしの道具店」におけるSREについての記事を書きました。 今回は、上の記事の中のスライド内で少しだけ触れていた「コンテナ技術(ECS/Docker)への移行」について、バッチ実行まわりでの技術選定や注意した点について紹介したいと思います。 ECS/Fargate移行前の課題「北欧、暮らしの道具店」はこれまで、AWSのOpsWorks(Chef)を使用しEC2の構成管理を行ってきました。 インフラ側の変更を反映するためには新しくプロビジョニングしたEC2を毎回用意する必要があるため、そのときには以下の様な課題を抱えていました。 - Web・APIサーバーとして動いているEC2インスタンスは、その数だけプロビジョニングを実行し新規

                          Laravel on ECSでのバッチ実行基盤事例|Kurashicom Tech Blog
                        • Well-Architected for Startups -信頼性の柱- 導入編 | Amazon Web Services

                          表: ホワイトペーパー より抜粋 いかがでしょうか。実際にはこの時間の中で対応の判断や復旧作業を行うのですが、年に数回発生することを考慮すると、それぞれの障害対応にかけられる時間は想像より短いのではないでしょうか。可用性の設計についてはホワイトペーパー内でも次のように触れられています。 私たちの推定では、復旧の実行を決定するまでに 30 分、復旧自体が 30 分以内に完了するとしています。この場合は障害から復旧するまで 60 分かかることになります。年間で障害が 2 件発生すると仮定すると、その影響時間は年間 120 分です。つまり、可用性の上限は 99.95% です。実際の可用性は、実際の障害発生率、障害の持続期間、各要因の実際の復旧速度によっても異なります。このアーキテクチャでは、プログラム更新のためにアプリケーションを一時的にオフラインにする必要がありますが、この更新作業は自動化され

                            Well-Architected for Startups -信頼性の柱- 導入編 | Amazon Web Services
                          • AWS モダンアプリケーション開発

                            AWS モダンアプリケーション開発 AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン 2019 年 10 月 注意 お客様は、この文書に記載されている情報を独自に評価する責任を負うものとします。 本書は、(a) 情報提供のみを目的としており、(b) AWS の現行製品とプラクティスを 表しますが、予告なしに変更されることがあり、(c) AWS およびその関連会社、サプ ライヤーまたはライセンサーからの契約義務や確約を意味するものではありません。 AWS の製品やサービスは、明示または暗示を問わず、いかなる保証、表明、条件を 伴うことなく「現状のまま」提供されます。お客様に対する AWS の責任は、AWS 契約により規定されます。本書は、AWS とお客様の間で行われるいかなる契約の一部 でもなく、そのような契約の内容を変更するものでもありません。 © 2019 A

                            • Introducing the AWS Load Balancer Controller | Amazon Web Services

                              Containers Introducing the AWS Load Balancer Controller The AWS ALB ingress controller allows you to easily provision an AWS Application Load Balancer (ALB) from a Kubernetes ingress resource. Kubernetes users have been using it in production for years and it’s a great way to expose your Kubernetes services in AWS. We are pleased to announce that the ALB ingress controller is now the AWS Load Bala

                                Introducing the AWS Load Balancer Controller | Amazon Web Services
                              • コンテナのセルフホストランナーの中でコンテナを使えるようにするrunner-container-hooks

                                以前にセルフホストランナーの知られざる機能であるジョブの前後に任意のスクリプトを実行できるhookを紹介しました。 今回はセルフホストランナーの知られざる機能の紹介第二弾としてactions/runner-container-hooksを紹介します。 runner-container-hooksは2023年現在では比較的新しい機能で、自分もいつ頃に知ったのかは覚えていないのですが、actions/runnerのリポジトリには2022年の4-5月頃に追加されていたようです。実装のpull-reqから少し遅れて5月には設計ドキュメントと言えるADRのpull-reqが出されています。 このADRを見たところ自分がセルフホストランナーを運用する上で今まではどうしても不可能であったコンテナの中で起動したセルフホストランナーの中でコンテナ型のactionなどが実行できないという制約を突破できることが

                                  コンテナのセルフホストランナーの中でコンテナを使えるようにするrunner-container-hooks
                                • AWS環境を可視化できるソリューション【Lucidscale】を使って構成図を自動生成してみた | DevelopersIO

                                  こんにちは。 繁松です。 はじめに AWS,Azure,GCPなどのクラウド環境を可視化できるサービス「Lucidscale」を使ってAWSの構成図を自動生成してみたのでブログにしました。 Lucidscaleを使うことで以下のような構成図を自動で生成することができます。 やってみた アカウント作成 Lucidscaleのアカウントを作成します。 https://lucidscale.com/ja 料金 2週間は無料で利用できます。 無料期間以降も継続利用する場合の料金は以下です。 インディビジュアルプラン(個人利用プラン) 1ユーザー(作成者):¥269,000/年 チームプラン(チーム利用プラン) 1ユーザー(作成者);¥269,000/年 1ユーザー(エクスプローラー):¥54,900/年 https://lucid.app/ja/pricing/lucidscale#/pricin

                                    AWS環境を可視化できるソリューション【Lucidscale】を使って構成図を自動生成してみた | DevelopersIO
                                  • Grafana+CloudWatchを使ったAWSマルチアカウントでのプロダクト監視基盤構築のご紹介 - ACES エンジニアブログ

                                    ACESのソフトウェアエンジニアの稲田です。私は普段、弊社で提供しているシステムのアーキテクト設計、MLOpsをメインに担当しております。 今回は、ACES Meetという弊社のAIプロダクトサービスをターゲットに弊社のサービス監視基盤を標準化した話について、事例紹介をしたいと思います。 営業支援AIツール「ACES Meet」 想定する読者 プロダクトサービスの品質可視化の重要性について 弊社が抱えていた課題と背景 技術選定の方針 プロダクト監視基盤設計 目的 要件 監視項目 サービス品質 システム詳細メトリクス アラート通知 システム構成 監視ダッシュボードの仕組み Amazon Managed GrafanaのAWSマルチアカウントのデータソースサポート Amazon Managed GrafanaのX-Rayサポート 監視ダッシュボードのデータソースの拡張性 コスト概算 Cloud

                                      Grafana+CloudWatchを使ったAWSマルチアカウントでのプロダクト監視基盤構築のご紹介 - ACES エンジニアブログ
                                    • Next.jsのIncremental Static RegenerationをVercel以外でやってみる - Sweet Escape

                                      本記事はNext.js Advent Calendar 2020の9日目です。 tl;dr Vercel以外でもIncremental Static Regenerationは可能 試した範囲ではフルに機能するのはコンテナで動かした場合のみ AWSのサーバーレスで動かすのは現時点で絶望的 はじめに 早速ですが、みなさん、次世代のStatic Site Generation(SSG)と言っても過言ではないIncremental Static Regeneration(ISR)はご存知でしょうか。 一応知らない人のためにすごく簡単に説明をすると、『リクエストに対して静的にビルドされたページを返しつつ、有効期限が過ぎたら非同期で静的ページの再生成をSSRで行う』っていうものです。Cache Controlにおけるstale-while-revalidateと同じような考え方が適用されたものとも言

                                        Next.jsのIncremental Static RegenerationをVercel以外でやってみる - Sweet Escape
                                      • 「“クールな”LLMアプリは簡単に作れるが、リリースレベルは難しい」 Azure OpenAIとCognitive Searchを使ったチャット機能開発

                                        プロンプティングからOpenAI API、さらには周辺のライブラリやHubのエコシステムまで広く活用の助けになる知見を共有し、みんなで手を動かして楽しむためのコミュニティ「ChatGPT Meetup」。3回目に登壇したのは、吉田真吾氏。HRテックのSaaS「CYDAS PEOPLE」における、ChatGPTを活用したチャット機能開発について発表しました。 HRテックのSaaS「CYDAS PEOPLE」のチャット機能にChatGPTを活用 吉田真吾氏:どうもみなさんこんばんは。今日私からは、本番リリースに向かってLLMアプリケーションを構築している話をしようかなと思います。 第0回(ChatGPT Meetup Tokyo #0)でもお話をしたのですが、私は現在、RAG(Retrieval-Augmented Generation)フローを使ったLLMアプリケーションを作っています。 サ

                                          「“クールな”LLMアプリは簡単に作れるが、リリースレベルは難しい」 Azure OpenAIとCognitive Searchを使ったチャット機能開発
                                        • Amazon ECS と AWS Fargate で動作する「LayerX インボイス」のコスト最適化手法 - LayerX エンジニアブログ

                                          こんにちは!LayerXの高際 (@shun_tak) です!過去にはOCR関連の記事を書きました! LayerX インボイスのアプリケーション・サーバーはAmazon ECS と AWS Fargateで動作しています。今回の記事ではそのコスト最適化手法について解説したいと思います。よろしくお願いします! tech.layerx.co.jp サマリーとしては、LayerX インボイスではオーソドックスに費用の削減とタスク数の最適化という2つの方法でコスト最適化を行っています。 Savings PlansとFargate Spotを活用した費用の削減 Auto ScalingとScheduled scalingによるタスク数の最適化 早速次節から解説していきます! Savings Plansを活用した費用の削減 Fargateは使った分だけ料金が請求されます(vCPU数×メモリサイズ×起動

                                            Amazon ECS と AWS Fargate で動作する「LayerX インボイス」のコスト最適化手法 - LayerX エンジニアブログ
                                          • re:Invent2019 AWSの新サービスの1行所感 Andy Jassyキーノート - プログラマでありたい

                                            2019年12月2日〜6日までアメリカのラスベガスでAWSの最大のイベントであるre:Inventが開催中です。今年も自分なりの解釈で1行所感をつけていきます。まずは、12/3のAndy Jassyのキーノートで発表したものです。 ※1行の定義はなんだという問には答えません。 CPU&インスタンス AWSが独自設計したCPU、"Graviton2 processors"を使った新インスタンスタイプM6g,R6g,C6g。Intelの新インスタンスの発表なかったから、CPUも内製化の方向なのかな? aws.amazon.com 機械学習向けのインスタンス Inf1。めっちゃ速いって aws.amazon.com ネットワーク 新サービスと出ているが、紹介もされなかった悲しいサービスたち aws.amazon.com AWS Transit Gateway Multicast マルチキャスト。

                                              re:Invent2019 AWSの新サービスの1行所感 Andy Jassyキーノート - プログラマでありたい
                                            • ECS on Fargate のセキュリティ対策は何をやるべき?開発者目線で考える/security-for-ecs-on-fargate-secjawsdays

                                              以下のイベント「Security-JAWS DAYS」で発表した際の登壇資料です。 https://s-jaws.doorkeeper.jp/events/155024

                                                ECS on Fargate のセキュリティ対策は何をやるべき?開発者目線で考える/security-for-ecs-on-fargate-secjawsdays
                                              • 30行くらいで作るはじめてのインフラ構築 | DevelopersIO

                                                AWS CDKでコードの記述30行ほどでVPC, ECS, Fargateなどを使ったインフラ環境を構築してみました。 HAPPY BIRTHDAY, クラスメソッド! 弊社には 7月7日の会社のお誕生日にブログ書くという文化があります。 せっかくなので私も最近はまっている CDK ネタで一本書いてみようと思います。 ついこの間、はじめて CDK を使って VPC 環境を構築する機会があったのですが、思いのほかシンプルだったのでご紹介したいと思います。 作るもの VPC、 ECS、 Fargateでインフラ環境を構築します。 使うもの AWS CDK を Typescript で記述します。 cdk --version 1.32.2 tsc -v Version 3.7.4 Typescript の watch モードをオンにする 私はよくビルドし忘れてデプロイの時にこけるので Watch

                                                  30行くらいで作るはじめてのインフラ構築 | DevelopersIO
                                                • MENTAをAWSに移行して振り返る(ECS/Fargate + Laravel編)

                                                  https://lancersrecruit.connpass.com/event/219434/ 【SPACEMARKET×Lancers】シェアリングエコノミーを支えるインフラ/SREでのスライドとなります。

                                                    MENTAをAWSに移行して振り返る(ECS/Fargate + Laravel編)
                                                  • AWSアカウント間のS3, DynamoDBデータ移行計画の記録 (背景と転送方法の検討) | DevelopersIO

                                                    はじめに こむろ@事業開発部です。 今回、5年以上稼働していた SpringBoot アプリケーションを エンドユーザーへの影響を最小にして、別のAWSアカウントへ完全に移行させました。その調査、検討、実施した際の想定外のトラブルやその対処について記録します。 私は主に全体のとりまとめを担当し、アプリケーション内で使うデータの関係性のチェックや移行作業全体のスケジュール作成、切り戻し計画の作成、メンバーへのタスク依頼、顧客調整等々を行いました。 概要 全体が無駄に長くなってしまったのでまとめると以下になります。 Elastic Beanstalk (1 Container Docker)で動作していた Spring Boot アプリケーションを、別の AWS アカウントの Fargate 環境へ引っ越し 作業時間は最大 5 時間 転送はもちろん、データの完全一致の保証も含めて 移行対象デー

                                                      AWSアカウント間のS3, DynamoDBデータ移行計画の記録 (背景と転送方法の検討) | DevelopersIO
                                                    • モノリシックなAPIでのカナリアリリース導入と開発者の認知負荷を減らすためConfigMapを使わない選択をした話 - MonotaRO Tech Blog

                                                      こんにちは、プラットフォームエンジニアリング部門コンテナ基盤グループの岡田です。 当社ではECサイトの裏側で利用されているモノリシックなAPIをコンテナ化し、Elastic Kubernetes Service (EKS) に移行しました。 移行直後は下記のようにトラブルに見舞われましたが、現状安定した運用ができています。 EKSコンテナ移行のトラブル事例:推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog EKSコンテナ移行のトラブル事例:FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blog 今回はトラブル事例ではなく活用事例になりますが、アプリケーションリリース起因でのトラブル影響を減らすため、コンテナ化したAPIに対してカナリアリリース導入を行いました。そのため、導入に際して生じたConfigやSecret周りの課題

                                                        モノリシックなAPIでのカナリアリリース導入と開発者の認知負荷を減らすためConfigMapを使わない選択をした話 - MonotaRO Tech Blog
                                                      • KubernetesクラスターからAWSリソースへのアクセスを制御してくれる「IRSA」とは? - Qiita

                                                        「アクセス制御」ってややこしいですよね。 AWSでもIAMが苦手!って方多そうですが、Kubernetesの世界でもアクセス制御を知っておかないとセキュリティ事故に繋がります。 今回はそれらの合わせ技となる、AWS上でKubernetesを使う際の両プラットフォーム間でのアクセス制御の組み合わせについてのお話です。 AWS上でKubernetesを使う際のセキュリティ課題 EKSを使ってKubernetesワークロードをAWS環境上でホストしてるよ!という方は多いんじゃないかと思います。 特にAWSでKubernetesを使っていると「PodからAWSリソースにアクセスさせたい」という要件が出てきます。 以下のようなプロダクトを例として想像してみましょう。 この例では同じEKSクラスター上でKubernetes Podを2種類がバックエンドアプリケーションとして稼働しています。 Pod①へ

                                                          KubernetesクラスターからAWSリソースへのアクセスを制御してくれる「IRSA」とは? - Qiita
                                                        • GitHub Actions で AWS を操作する(Lambda編) - BIGLOBE Style | BIGLOBEの「はたらく人」と「トガッた技術」

                                                          こんにちは。開発部門(プロダクト技術本部)の宮下です。 BIGLOBE では GitHub Actions による作業効率化に取り組んでいます。 本記事では、GitHub Actions が得意とする点を踏まえつつ、AWS Lambda と連携して手作業を大幅に減らす実例をソースコード付きで紹介します。 想定読者 GitHub Actions を使うと何がうれしいのか? 代表的なユースケース あまり向かないユースケース 事例紹介 課題 改善後 API コンテナ リグレッションテスト用 Lambda パフォーマンステスト用 Lambda 自動化による効果 Lambda を実行するアクション GitHub Actions で使えるアクション ソースコード ポイント、はまったところ GitHub Actions の制御 / ステップ間での値の受け渡し GitHub Actions の制御 / 複

                                                            GitHub Actions で AWS を操作する(Lambda編) - BIGLOBE Style | BIGLOBEの「はたらく人」と「トガッた技術」
                                                          • 独学で未経験のモダンな技術を学習してポートフォリオを作るまで【Rails / Next.js / AWS / Docker / GitHub Actions】 - Qiita

                                                            独学で未経験のモダンな技術を学習してポートフォリオを作るまで【Rails / Next.js / AWS / Docker / GitHub Actions】RailsAWS初心者個人開発Next.js はじめに こんにちは!きいな(@keynyaan)と申します。 今回、モダンな技術を使って初めてポートフォリオを作ってみたので、開発背景や学習教材などを紹介します。 ポートフォリオを作るにあたって、色々な方の素晴らしいポートフォリオ作成記事が参考になったので、今度は私の記事が誰かのためになることを祈ってます。 自己紹介 大学卒業後、新卒でSIer企業に入社し、3年ほどJavaやJavaScriptなどを使って、バックエンドやフロントエンドのシステム開発を行っていました。 そんな私が自社開発企業に興味を持ち、退職を機に、2023年1月からポートフォリオ作成に向けて学習を始めました。 学習期間

                                                              独学で未経験のモダンな技術を学習してポートフォリオを作るまで【Rails / Next.js / AWS / Docker / GitHub Actions】 - Qiita
                                                            • ECSで作業用のタスクをサクッと作るためのツールを作成した - カンムテックブログ

                                                              インフラエンジニアの菅原です。 最近、バイクに念願のグリップヒーターをつけました。 これでツーリング時の手の寒さが多少楽になりそうで喜んでいます。 とはいってもなかなか出かけられないのですが… 現在私はAWS Fargateを使ったサービスをECS上に構築を進めており、日々コンテナと戯れています。 基本的にストレージ以外のコンポーネントはほとんどECSで動いているのですが、VPCのネットワーク内でちょっとした作業(たとえばネットワークの疎通確認など)をしたい場合、都度新しいタスクを起動して作業しています。 また、DBにテストデータを入れたかったり、どうしてもDBを直接操作したいことがある場合、stoneを新しいタスクを起動した上で、そのタスクを踏み台としてaws ssm start-sessionでポートフォワーディングを行い、手元から直接DBにアクセスできるようにしたりしています。 しか

                                                                ECSで作業用のタスクをサクッと作るためのツールを作成した - カンムテックブログ
                                                              • 【衝撃に備えろ】Fargate PV1.4のVPCエンドポイント変更点について | DevelopersIO

                                                                こんばんわ、札幌のヨシエです。(亜人大好きです、よつばと!と同じぐらい好きです) コンテナ業界盛り上がってますね、中でもFargateのプラットフォームがアップデートされ様々な新機能が追加されてます。 挙げるとキリがないですがFargate PV1.4からコンテナエンジンがDockerからcontainerdに切り替わり、様々な変更が加えられております。 詳しくは↓をご確認ください。 その中でFargate(PV1.4)の発表があった時は「あーはいはい、中身が変わるんですね。わかりました。まぁコンテナホストのバージョンが上がってもコンテナが起動することだけ確認すれば良さそうっすね」と考えておりましたが、 AWSドキュメントに以下の記載を確認しました。 Fargate 起動タイプおよびプラットフォームバージョン 1.3.0 以前を使用する Amazon ECS タスクでは、この機能を活用する

                                                                  【衝撃に備えろ】Fargate PV1.4のVPCエンドポイント変更点について | DevelopersIO
                                                                • EKS on Fargate:virtual-kubelet の違い + Network/LB 周りの調査 - @amsy810's Blog

                                                                  EKS on Fargate こんにちは。 サイバーエージェントの青山(@amsy810)です。 この記事は Kubernetes3 Advent Calendar の 4日目の記事です(EKS #2 にもクロスポストしています)。 re:Invent で EKS 関連の何かしらの発表がされることを見越して Advent Calendar を埋めたので、書くネタが見つかってホッとしています。 KubeCon 会期中に 「Managed Worker Node for EKS」 がリリースされ歓喜の声が上がりましたが、今回は re:Invent で 「EKS on Fargate」 がリリースされ歓喜の声が上がっているようです。 今回は EKS on Fargate のアーキテクチャを見ていきたいと思います。virtual-kubelet と近いと思ってますが果たして。 (EKS on Fa

                                                                    EKS on Fargate:virtual-kubelet の違い + Network/LB 周りの調査 - @amsy810's Blog
                                                                  • SREチームで社内GameDayを実施しました

                                                                    GameDayとは 起源はAWSが毎年行っているAWS re:inventの中で開催される行事の1つです。 チームを組んでクラウド・アプリケーションを襲う謎の障害や悪意のある攻撃に対処し、トラブルシューティング能力を競うコンテストとなっています。 のちに様々な企業が社内でも実施するようになり、今ではAWS Well-Architectedのセキュリティ項目でもその実施が推奨されています。 ゲームデーを実施する ゲームデーを実施する: さまざまな脅威について、インシデント対応イベントのシミュレーション (ゲームデー) を実施します。このゲームデーには、主要なスタッフや管理者を参加させてください。 教訓から学ぶ: ゲームデーの実行から得られた教訓は、プロセスを改善するためのフィードバックに含まれている必要があります。 GameDayの手順 今回社内で行なったGameDayの流れです。 1. 発

                                                                      SREチームで社内GameDayを実施しました
                                                                    • スタディスト開発部が目指す SRE の未来と現状と Kubernetes

                                                                      (上記ブログ執筆時は、EKS on EC2 へ移行予定でしたが、EKS on Fargate への移行を行う方針に切り替えました。) Kubernetes 移行に関連する技術面の話題についてはご紹介してきた一方で、これまでの記事では、 「なぜ Kubernetes 移行を行っているか?」「スタディスト開発部は、最終的に何を目指しているのか?」といった背景には触れておりませんでした。そこで本記事では、スタディスト開発部が目指す世界観と、その過程として歩んでいる Kubernetes 移行の位置づけについてご紹介します。 目次Teachme Biz における Infra の現在と抱えている課題スタディスト開発部が目指す世界観Kubernetes 移行の位置づけ今後のやりたいことTeachme Biz における Infra の現在と抱えている課題現在 Teachme Biz の大部分(以降、本記

                                                                        スタディスト開発部が目指す SRE の未来と現状と Kubernetes
                                                                      • 【AWS】Next.js+LaravelをECS+Fargateにデプロイする時のアレコレ | yutaro blog

                                                                        最近業務でNext.js+LaravelのアプリケーションをAWSのAmazon ECS(Fargate)にデプロイするタスクを担当しているので、デプロイするにあたりNext.js側、Laravel側でやっておくこと、エラー対応などをまとめておく。 ECSへのデプロイはEC2へのデプロイに比べそもそもネットに情報が少ないECSの中でもデータプレーン(コンテナ実行環境)にEC2を使った記事が多くFargateを使った記事はかなり少ないECS+Fargateへのデプロイでも本記事のようなフロントエンド+APIの構成のデプロイ例はマジで少ない という状態で結構苦戦したので、自分で苦戦したことを残しておくとともに同じ構成でデプロイする方に向けて参考になれば嬉しいです。 ECS、ECR、Fargateについての技術説明・全体的なデプロイ作業の手順についてはこの記事では扱わないが、この記事(というかZ

                                                                          【AWS】Next.js+LaravelをECS+Fargateにデプロイする時のアレコレ | yutaro blog
                                                                        • 最もリスクの高いAWS構成トップ3 #aqua #コンテナ #セキュリティ - クリエーションライン株式会社

                                                                          本ブログは「Aqua Security」社の技術ブログで2021年1月20日に公開された「 The 3 Riskiest Cloud Native AWS Configurations 」の日本語翻訳です。 EC2 だけでも数十もの主要なセキュリティ設定が可能なため、AWS の設定オプションの多さに圧倒されることがあります。複雑さが増す一方で、クラウドネイティブデプロイメントにおいて動的なインフラ要件に対応するには、クラウドアカウントを適切に、そして安全に設定することが重要です。サービスを適切に設定するという課題は、利用可能な AWS サービスの数が膨大であり、それぞれが独自の要件を持っているため、さらに複雑になっています。 AWS のクラウドサービスは、新しいサービスの提供や定期的なアップデートなどで常に変動し、CSPM(Cloud Security Posture Management

                                                                            最もリスクの高いAWS構成トップ3 #aqua #コンテナ #セキュリティ - クリエーションライン株式会社
                                                                          • AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」

                                                                            同社が障害明けの26日に行った、エンジニアチームによる障害の振り返り会議に記者も同席した。「障害発生当初、いろいろなジョブに影響が出たため何が起きているのか分からなかった」「各サービスを管理するAWSマネジメントコンソールの動きもおかしく、問題に対応しようとしても何度もリトライしないとインスタンスが立ち上がらなかった」「AWS CLI(コマンドによる管理ツール)は比較的調子が良かった」──など、現場の生々しい声が飛び交った。 一方、「『AWS Fargate』で運用しているサービスは自動復旧できた」という報告も上がった。Fargateはサーバなどの管理をAWS側に任せてコンテナを実行できる、いわゆる「サーバレス」のサービスだ。 会議では、「バッチ処理サーバをコンテナ化するのが、今後の対応策の一つだろう」という意見でまとまった。コンテナ化してFargateで運用すればAWS側が可用性を自動管

                                                                              AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」
                                                                            • Lancers本番環境のコンテナ化が完了しました | ランサーズ(Lancers)エンジニアブログ

                                                                              Lancers Engineer Blog をご覧のみなさんこんにちは。開発部/技術基盤 SREの安達(@adachin0817)です。以下前回のブログから3ヶ月経ちましたが、ついにLancersのBatch、AppサーバーをEC2からECS/Fargateに移行完了しました。 そして長年自前で運用していたデプロイシステムを廃止して、CI/CDはCircleCIに完全統一しました。これにて、Lancersの全サービスをコンテナに移行完了となりました。 ※見ていない方はぜひ一読してもらえると幸いです。 ・LancersをAmazon Linux2へログ基盤のリニューアルと管理画面をECS/Fargateに移行しました 旧開発環境、EC2での運用課題 Ansibleコンテナによる開発環境の統一により工数がかかる 本番コンテナ化以前は、EC2で利用しているAnsibleの管理を開発環境にも適用す

                                                                                Lancers本番環境のコンテナ化が完了しました | ランサーズ(Lancers)エンジニアブログ
                                                                              • ReproのImport/Exportを支えるサーバーレスアーキテクチャ

                                                                                Architect New World On AWS 2022 というオンラインイベントで登壇した際の発表資料です。 cf. https://www.sbbit.jp/eventinfo/69957/ AWSのLambda, Fargate, Step Functionsを組み合わせてサーバーレスでスケーラブルなデータインポートプラットフォームを構築したノウハウについて解説する内容になります。

                                                                                  ReproのImport/Exportを支えるサーバーレスアーキテクチャ
                                                                                • EKSコンテナ移行のトラブル事例:FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blog

                                                                                  こんにちは!SREグループ コンテナ化推進チームの楠本です。 EKSへのコンテナ移行では、これまで紹介した記事以外にも様々なトラブルがありました。 EKSコンテナ移行のトラブル事例:ALBの設定とPodのライフサイクル管理 - MonotaRO Tech Blog EKSコンテナ移行のトラブル事例:推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog 今回のトラブルでは、コンテナ移行に伴ってSLOが未達状態になりエラーバジェットを急激に消費してしまいました。 その対策としてマルチAZ間の通信遅延の解消をEKS on Fargateで実施したお話をご紹介します。 先に断っておくと私自身がアプリケーション開発者だったため、 インフラの話は都度インフラの方からサポートを受けながら対応しました。そのためズレている点などあればご了承ください。 VMからEKS on

                                                                                    EKSコンテナ移行のトラブル事例:FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blog