並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 369件

新着順 人気順

Fargateの検索結果1 - 40 件 / 369件

  • AWSの膨大で複雑なサービス群をすべて「たった1行」で説明していくとこうなる

    AmazonのクラウドサービスであるAWSは、コンピューティングやデータベース、ストレージなど、膨大で複雑なサービスで構成されています。こうした豊富なサービス群をうまく組み合わせて利用する「ビルディングブロック」がAWSのメリットでもありますが、サービス数が多すぎてなかなか全体像を把握できないのも事実。フリーランスのエンジニアでありコンサルタントでもあるジョシュア・テイセン氏が自身のブログで、AWSのすべてのサービスを「たった1行」で説明しています。 Amazon Web Services https://adayinthelifeof.nl/2020/05/20/aws.html テイセン氏によると、Amazon Dashboardから利用可能なAWSのサービスは記事作成時点で163あるとのこと。そのすべてを正確に理解する必要はありませんが、基本を押さえておくことはいいことであり、問題の

      AWSの膨大で複雑なサービス群をすべて「たった1行」で説明していくとこうなる
    • 1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary

      自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

        1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
      • Docker一強の終焉にあたり、押さえるべきContainer事情

        章立て はじめに Docker・Container型仮想化とは Docker一強時代終焉の兆し Container技術関連史 様々なContainer Runtime おわりに 1. はじめに Containerを使うならDocker、という常識が崩れつつある。軽量な仮想環境であるContainerは、開発からリリース後もすでに欠かせないツールであるため、エンジニアは避けて通れない。Container実行ツール(Container Runtime)として挙げられるのがほぼDocker一択であり、それで十分と思われていたのだが、Dockerの脆弱性や消費リソースなどの問題、Kubernetes(K8s)の登場による影響、containerdやcri-o等の他のContainer Runtimeの登場により状況が劇的に変化している。本記事では、これからContainerを利用したい人や再度情報

          Docker一強の終焉にあたり、押さえるべきContainer事情
        • Amazon VPCを「これでもか!」というくらい丁寧に解説 - Qiita

          はじめに AWS上で仮想ネットワークを構築できるAmazon VPCは、多くのAWSサービスが動作する基盤となる、非常に重要かつ多機能なサービスです。 多機能ゆえに公式ドキュメントやネット上の記事も断片的な機能の解説が多く、全体像を把握することが難しいサービスとも言えます。 そこで本記事はVPCの全体像を理解できるよう、各機能のつながりや動作原理を丁寧に解説し、 「VPC界の百科事典」 (あくまで例えですが…笑) となるような記事を目指したいと思います。 【追記】 実践編の記事を追加しました VPCの実画面での構築方法は、以下の別記事にまとめました。「VPCを実際に触ってみたい!」という方は、こちらもご一読いただけると嬉しいです。 VPCとは 「Virtual Private Cloud」の略で、クラウド上に仮想的なネットワークを構築するためのサービスです。 例えば、オンプレ環境でWebア

            Amazon VPCを「これでもか!」というくらい丁寧に解説 - Qiita
          • Kubernetes、やめました | 外道父の匠

            最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね?って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ?って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ

              Kubernetes、やめました | 外道父の匠
            • 【2020年】AWS全サービスまとめ | DevelopersIO

              このエントリは、2018年、2019年に公開したAWS全サービスまとめの2020年版です。これまではいくつかに分割して公開していましたが、1エントリにまとめてほしいという要望をもらっていたため、今年は1エントリに集約してみました。 こんにちは。サービスグループの武田です。 このエントリは、2018年、2019年に公開した AWS全サービスまとめの2020年版 です。これまではいくつかに分割して公開していましたが、1エントリにまとめてほしいという要望をもらっていたため、今年は1エントリに集約してみました。どちらがいいのか正直わからないので、フィードバックなどあれば参考にさせていただきます。 2020-01-08 リクエストがあったためAmazon Mechanical Turkを追加。 2018年まとめ 【2018年】AWS全サービスまとめ その1(コンピューティング、ストレージ、データベー

                【2020年】AWS全サービスまとめ | DevelopersIO
              • 「1億台の常時接続」を実現せよ! Nintendo Switchのプッシュ通知システム全面刷新の裏側 (1/3)

                アマゾン ウェブ サービス ジャパンは、2024年6月20日と21日、国内最大の年次イベントである「AWS Summit Japan」をハイブリッドで開催。150を超えるセッションが展開された。 本記事では、ニンテンドーシステムズによるセッション「Nintendo Switch向けプッシュ通知システムのリプレイス事例」をレポートする。登壇したのは、同社 システム開発部の林愛美氏と坂東聖博氏だ。 2017年のNintendo Switchの発売とあわせてリリースされた「プッシュ通知システム」。同社は、長期運用を見据えて、よりクラウドネイティブなシステムへのリプレイスを決定するが、大量のTCP接続を維持するための様々な課題が立ちふさがった。 本セッションでは、AWS FargateやNetwork Load Balancer(NLB)といったAWSのマネージドサービスを用いた、“最大1億台”級

                  「1億台の常時接続」を実現せよ! Nintendo Switchのプッシュ通知システム全面刷新の裏側 (1/3)
                • 転職活動の面接でいただいた質問集 - Qiita

                  この度転職活動を行って無事内定をいただいたので、記念に面接の中でいただいた質問をまとめてみました。 某大手金融のフィンテックエンジニアに転職します!! 転職活動当初は、レガシー、ジョブホッパー、経験少でダメ出しの嵐🍃 でも諦めずNuxt+Firebaseでのサービス開発、マイクロサービス化ポートフォリオ、CTFの取組、GitHub毎日コントリビュート、個人活動も頑張って内定頂けて本当よかった😁 — bindingpry (@bindingpry) November 19, 2021 基本的に技術面接では、履歴書や実務経験の技術、ポートフォリオで扱っている技術、自分で口にした技術を深ぼられることが多かったです。 そこはしっかり技術を扱えるだけでなく説明できるようにすることも必要だと思いました。(自分は最初ボロボロでしたが笑) また正社員の面接では技術と同等に、仕事への姿勢、性格、事業への

                    転職活動の面接でいただいた質問集 - Qiita
                  • Kubernetesをだいたい理解するまで

                    インフラ初心者がいきなり実務でKubernetesを使うことになったので、その学習記録✎ 流れとしては、 概念的なところを抑える 実際に手元で動かしてみる です! また、すでにKubernetesについて書かれたわかりやすい記事がたくさんあるので、本記事はそれらをもとに自分の理解をまとめたものになります。 概念的なこと まずはこれで概要把握 まずは👇を読もう。(ありがたやありがたや...) 僕らは何故Kubernetesを使うのか Kubernetesというものが出てきた背景を、オンプレの時代からどういうふうに変わっていったかわかる KUbernetesの概要がわかる メリデメがわかる Argo CDの例などを用いてどういうふうに使われているのかイメージが付く Kubernetesとは ざっくりいうと、 サービスをコンテナ上で動かすようになったことで起こった、 複数のサーバ上で複数のコン

                      Kubernetesをだいたい理解するまで
                    • 転職活動の面接でいただいた質問集 - Qiita

                      この度転職活動を行って無事内定をいただいたので、記念に面接の中でいただいた質問をまとめてみました。 某大手金融のフィンテックエンジニアに転職します!! 転職活動当初は、レガシー、ジョブホッパー、経験少でダメ出しの嵐🍃 でも諦めずNuxt+Firebaseでのサービス開発、マイクロサービス化ポートフォリオ、CTFの取組、GitHub毎日コントリビュート、個人活動も頑張って内定頂けて本当よかった😁 — bindingpry (@bindingpry) November 19, 2021 基本的に技術面接では、履歴書や実務経験の技術、ポートフォリオで扱っている技術、自分で口にした技術を深ぼられることが多かったです。 そこはしっかり技術を扱えるだけでなく説明できるようにすることも必要だと思いました。(自分は最初ボロボロでしたが笑) また正社員の面接では技術と同等に、仕事への姿勢、性格、事業への

                      • Web アプリケーションにおける Amazon ECS / AWS Fargate アーキテクチャデザインパターン - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

                        こんにちは。AWS Container Hero の新井です。 Amazon ECS の登場から間もなく 10 年が経ちますが、その間、ECS ⾃体の進化に加えて、さまざまな AWS マネージドサービスとの連携が可能になりました。 現在では、コンテナベースのワークロードを活⽤することで実現できないことを探す⽅が難しいほど、柔軟なアーキテクチャが構築できるようになっています。 しかし、⾃由度が⾼い分、要件に合ったアーキテクチャを模索する際には、迷うことも多いでしょう。 AWS上でシステムを適切に構築するためには、あらかじめサービス間のつなぎ⽅やパターン、その特徴を把握しておくことが重要です。 これにより、フィージビリティを迅速に確認でき、その後のトライアンドエラーのサイクルを加速させることができます。 今回は、最新の AWS サービスアップデートを踏まえつつ、Amazon ECS / AWS

                          Web アプリケーションにおける Amazon ECS / AWS Fargate アーキテクチャデザインパターン - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
                        • Amazon ECS でのコンテナデプロイの高速化

                          Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション

                            Amazon ECS でのコンテナデプロイの高速化
                          • 東京大学の講義「AWSによるクラウド入門」をTypeScriptで写経した - dackdive's blog

                            AWSによるクラウド入門 少し前に話題になっていた東京大学の講義資料をやってみたので、内容、感想などメモ。 講義で使用するソースコードはすべて Python で書かれていますが、自分が実際に使うとしたら TypeScript で書くだろうなと思ったので TypeScript で写経しました。 が、CDK のコードはすべて TypeScript で書けましたが、Lambda 関数や動作確認用のスクリプトなどを全て置き換えるところまでは至らず、Python のままです。 写経したリポジトリは https://github.com/zaki-yama-labs/intro-aws に。 学べること 本講義資料には全部で5つのハンズオンがあります。 各ハンズオンで利用する AWS のサービスについては以下の通り。 全般 AWS CDK: Cloud Development Kit CloudFor

                              東京大学の講義「AWSによるクラウド入門」をTypeScriptで写経した - dackdive's blog
                            • [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 | DevelopersIO

                              [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 DevelopersIO 2021 Decadeで登壇した動画や資料を掲載、解説をしています。AWSのセキュリティについて網羅的に扱っています。ちょー長いのでご注意を。 こんにちは、臼田です。 みなさん、AWSのセキュリティ対策してますか?(挨拶 ついにやってまいりました、DevelopersIO 2021 Decade!私は「[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで]」というテーマで登壇しました。 動画と資料と解説をこのブログでやっていきます。 動画 資料 解説 動画はちょっぱやで喋っているので、解説は丁寧めにやっていきます。 タイトル付けの背景 今回何喋ろうかなーって思ってたら、2年前のDeve

                                [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 | DevelopersIO
                              • 熱量を失ったサーバーレスという世界(個人の所感) - Sweet Escape

                                はじめに 先日、エンジニア界隈では有名なポッドキャストであるfukabori.fmに出させていただきまして、そのときのトピックがサーバーレスでした。 ポッドキャストはこちらで聞けますのでぜひどうぞ。 fukabori.fm そこでもいろいろお話ししたのですが改めて話せなかったことなども含めて書こうかなと。つまり、ポエムです。散らかった文章な上に少し長めなのでお時間のある方だけどうぞ。 なお、サーバーレスの黎明期の話とかそういう思い出話は以前に書いたこちらの投稿があります。 サーバーレスと僕のこれまでとこれから - Sweet Escape 今回は思い出話ではなく、サーバーレスに個人として魅力を感じ、仕事としてその良さを広めたり、実装のお手伝いをし続けてきた自分がそういった仕事から離れた2022年現在どういう風に向き合ってるかについてのポエムです。 前提 現在の自分は株式会社Singular

                                  熱量を失ったサーバーレスという世界(個人の所感) - Sweet Escape
                                • とりあえずWebサービス作る時の私の技術選定ポイント@2022/02

                                  はじめに inspired mogaさんのブラウザで動くサービスを作るときの技術選定が素晴らしい記事だったので、自分も書いてみる事にしました。 幸いにも技術選定からのお仕事をする機会が多くて、自分の中でパターンが大体決まってきているので言語化してみます。前提が同じサービスは無いので絶対的な正解は無いですが、なんかしらの参考になれば幸いです。 ※2022/02時点 私/よくあるお仕事について Web系のサービスなんかいい感じにするマンとして、フリーランスとして働いています。 準委任という形でスタートアップ企業をお手伝いする事が多いです。 MVPを作りたい、もしくはMVPは行けたのでちゃんと作り直したい、という要望があって参画して、まるっと作ってそのまま運用をします。作って終わりではなくて、運用や拡張性を考えてやってます(サービスに必要なのはもちろん、運用する自分が楽だから)。 前提 エンジニ

                                    とりあえずWebサービス作る時の私の技術選定ポイント@2022/02
                                  • 「無人化システム」を駆逐する組織マネジメントとエンジニアリング

                                    弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい

                                      「無人化システム」を駆逐する組織マネジメントとエンジニアリング
                                    • デプロイ今昔 - Hatena Developer Blog

                                      こんにちは。はてなのアプリケーションエンジニアの id:onk です。 最近、若手エンジニアを中心に、いろいろな技術を見つめ直すワーキンググループをやっています。今回は、その中から「デプロイ」の会で発表されたことをまとめました(なお、私は会のとりまとめをやっている非若手です)。 デプロイのライフサイクルの違い Infrastructure Platformでのデプロイ Application Runtime Platformでのデプロイ Applicationsのデプロイ デプロイ方式はどのように変化してきたか In place から Blue/Green へ Immutable Infrastructure という考え方 オートスケールへの対応 push 型デプロイと pull 型デプロイ コンテナによるデプロイの現況 コントロールプレーンによって何が変わったか ECS におけるデプロイ

                                        デプロイ今昔 - Hatena Developer Blog
                                      • AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠

                                        これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス:ALB or ECS Service 共有 or 1環境毎 アクセスログ:ALB or WEBサーバー ECS / EKS デプロイ:Blue/Gr

                                          AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
                                        • AWS公式『現代的なウェブアプリケーションの構築』ハンズオンのハマリどころ - Qiita

                                          AWSは、AWSのサービスを活用した実践的なハンズオンコンテンツを多数公開しており、 日本語化もされています。 アマゾン ウェブ サービス (AWS) の実践的チュートリアル https://aws.amazon.com/jp/getting-started/hands-on/ 社内向けにコンテナやAPI Gateway初学者向けのハンズオン教材を探していたところ、 ちょうどいいチュートリアルをみつけました。 現代的なウェブアプリケーションの構築 https://aws.amazon.com/jp/getting-started/hands-on/build-modern-app-fargate-lambda-dynamodb-python/ このチュートリアル、 ECS/Fargateを活用したコンテナアプリケーションの公開 Codeサービスを活用したCI/CDパイプラインの構築 Ama

                                            AWS公式『現代的なウェブアプリケーションの構築』ハンズオンのハマリどころ - Qiita
                                          • JP Contents Hub

                                            AWS 日本語ハンズオン Amazon Web Services(AWS) の 日本語ハンズオンやワークショップを、カテゴリごとにまとめています。 右側の目次や、ヘッダー部分の検索ボックスから、各コンテンツにたどり着けます。 また、Ctrl + F や command + F を使ったページ内検索もご活用いただけます。 料金について ハンズオンで作成した AWS リソースは通常の料金が発生します。作成したリソースの削除を忘れずにお願いします。 もし忘れてしまうと、想定外の料金が発生する可能性があります。 画面の差異について ハンズオンで紹介されている手順と、実際の操作方法に差異がある場合があります。 AWS は随時アップデートされており、タイミングによってはハンズオンコンテンツが追いついていない事もあります。 差異がある場合、AWS Document などを活用しながら進めて頂けますと幸い

                                              JP Contents Hub
                                            • 個人的AWS ログ管理のベースライン - mazyu36の日記

                                              AWSのログ管理についてはいくつか考えるポイントがあると思います。 どのログを保存するか。 CloudWatch Logs(以下CW Logsと記載)とS3のどちらに保存するか、もしくは両方に保存するか などなど。 システムの特性によるところも多いかと思いますが、自分の中でのログ管理のベースラインが定まりつつあるので、頭の整理がてらまとめます。 自分の中での大まかな方針としては以下です。 S3に保存できるものは基本S3に保存する。 以下の場合は、CW Logsに保存する。必要に応じてS3に転送する。 アラームを出したい場合 さっとCW Logs Insightでログを確認したい場合 CW Logs に出さざるを得ない場合 全体像としては以下になります。 なおあくまで個人的な経験に基づくものなので、実際にはシステムの特性を踏まえて方針の決定が必要かと思います。 またこれは必要、これは不要など

                                                個人的AWS ログ管理のベースライン - mazyu36の日記
                                              • AWS監視アラート 事始め - mazyu36の日記

                                                はじめに 入門監視をはじめ一般的な監視に関するプラクティスは出回っているものの、AWSで具体的に何を監視するか?そのとっかかりについてはあまり出回っていないような気がします。 AWSの監視ってみんな何監視してるんすか…っていうぐらい実例あまり見つからないな。門外不出?— mazyu36 (@mazyu36) 2023年2月14日 どこまで監視するかは基本的にシステムの特性によると思います。一方でAWSのサービスごとにシステムによらずよく監視で使う項目というのもあるかと思います。 今回は過去の経験をもとに、最低限この辺りは監視することが多いかなというものをまとめてみます。全体像としては以下になります。 最低限これは監視しないとダメでしょ、とかこれは不要でしょ、などなどあるかと思います。そういうのがあればぜひコメントいただきたいです。 はじめに 「監視」について 前提 1-1. Webサービス

                                                  AWS監視アラート 事始め - mazyu36の日記
                                                • 【Web】知っておきたいWebエンジニアリング各分野の基礎知見80

                                                  この記事は? それぞれが専門にしている領域に関わらず、Webエンジニアリングの基礎知識として知っておきたいと思う事を対話形式でまとめていく。知識はインプットだけではなく、技術面接や現場では、専門用語の正しい理解をもとにした使用が必要なので、専門がなんであれ理解できるようなシンプルな回答を目指したものになっています。解答の正しさはこれまでの実務と各分野の専門書をベースに確認してはいますが、著者は各技術の全領域の専門家ではなく100%の正しさを保証して提供しているものではないので、そこはご認識いただき、出てきたキーワードの理解が怪しい場合各自でも調べ直すくらいの温度感を期待しています。なお、本記事で書いている私の回答が間違っている箇所があったりした場合、気軽にコメント欄などで指摘いただけるとありがたいです。 Webエンジニアリングの基礎 この記事でカバーしている領域は、以下のような領域です。W

                                                    【Web】知っておきたいWebエンジニアリング各分野の基礎知見80
                                                  • 【2021年】AWS全サービスまとめ | DevelopersIO

                                                    こんにちは。サービスグループの武田です。このエントリは、2018年から公開しているAWS全サービスまとめの2021年版です。 こんにちは。サービスグループの武田です。 このエントリは、2018年から毎年公開している AWS全サービスまとめの2021年版 です。昨年までのものは次のリンクからたどってください。 AWSにはたくさんのサービスがありますが、「結局このサービスってなんなの?」という疑問を自分なりに理解するためにまとめました。 今回もマネジメントコンソールを開き、「サービス」の一覧をもとに一覧化しました。そのため、プレビュー版など一覧に載っていないサービスは含まれていません。また2020年にまとめたもののアップデート版ということで、新しくカテゴリに追加されたサービスには[New]、文章を更新したものには[Update]を付けました。ちなみにサービス数は 205個 です。 まとめるにあ

                                                      【2021年】AWS全サービスまとめ | DevelopersIO
                                                    • AWSでバッチ処理を実装する際の選択肢とサービス比較

                                                      処理が複雑でジョブの依存関係を定義したい場合は、AWS Batch 単体で制御するか、より複雑な場合は Step Functions を用いて Lambda、ECS(Fargate)、AWS Batch(Fargate) を組み合わせる。 AWSにおけるバッチ処理の選択肢 ざっくりとした選択肢は下記。 Lambda ECS(Fargate) AWS Batch(Fargate) これらのサービスに実際は SQS や Step Functions を組み合わせることもあるので選択肢はさらに広がる。 ちなみに、SQS + Fargate(常時起動でポーリング) という構成や、SQS + Lambda + Fargate(都度実行) という構成は、AWS Batch が Fargate に対応した現在は特にメリットがないので取り扱わない。 2021/5/2 追記 「常時リクエストがくるユースケー

                                                        AWSでバッチ処理を実装する際の選択肢とサービス比較
                                                      • いまNext.jsで新規サービスを立ち上げるときの観点(Router・CSS・認証・監視など/2023年末)

                                                        免責事項 社内向けに展開するように雑にまとめました Next.jsの知見が深くない人がリードしてPoCを立ち上げなきゃいけなくなったが、社内的にはNext.jsを推奨しているみたいな場面を想定しています なので自信ないところも多いですが割と断言するように心がけて書いています PoCの立ち上げ想定なので、jest/Storybookなど内部品質面についてあまり深く書くことを避けています ほぼ自分の知識だけで書いており私見も多いですし、そもそも自分自身がトップクラスの知識や視座を有しているわけでもないので、まずは以下の話を理解はした上で、踏襲するかどうかは別途他記事やGitHub、公式ドキュメントなどを漁って判断することを推奨 App RouterかPages Routerか 2023年末現在まだApp Routerは技術記事が足りてきている印象ではないため、社内でノウハウを積極的に貯めていく

                                                          いまNext.jsで新規サービスを立ち上げるときの観点(Router・CSS・認証・監視など/2023年末)
                                                        • 6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 - データエンジニアの酩酊日記

                                                          ここ半年ぐらい、かなり久々にクラウド使ってアプリやバッチの基盤作ったりしてきて、色々と思ったことを書き捨てる。 「ちょっと検証してみた」程度のものも含めれば、AWSとGCPは一通り主要なマネージドサービスを触ったし、実際に複数のアプリやらバッチやらをマネージドサービス上で本番稼働させて今も運用してるけど、結局DB以外は基本全部Kubernetesに乗せるのが一番楽だと強く思うようになった。 Kubernetesは学習コストや運用コストがそれなりに高く付くから安易に採用するのはどうなのか、みたいな論調もあるし、つい半年前までは自分もそう思ってた。サーバレスなマネージドサービスが色々出てきているのに、なんでわざわざKubernetesクラスタなんていう設計、運用に手間のかかるクラスタリングサーバーを立てて管理しないとならんのかと。 だけど、実際にいくつかのマネージドサービス使ってアプリやバッチ

                                                            6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 - データエンジニアの酩酊日記
                                                          • データ基盤にありがちな「何を使って作ればよいか?」という問いに対する処方箋を用意してみました. - Lean Baseball

                                                            ちょっと昔まではデータ基盤の管理人・アーキテクト, 現在は思いっきりクラウドアーキを扱うコンサルタントになったマンです. 私自身の経験・スキル・このブログに書いているコンテンツの関係で, 「データ基盤って何を使って作ればいいの?」的なHow(もしくはWhere)の相談. 「Googleのビッグクエリーってやつがいいと聞いたけど何ができるの?」的な個別のサービスに対するご相談. 「ぶっちゃけおいくらかかりますか💸」というHow much?な話. 有り難くもこのようなお話をよくお受けしています. が, (仕事以外の営みにおける)個人としては毎度同じ話をするのはまあまあ疲れるので, データ基盤にありがちな「何を使って作ればよいか?」という問いに対する処方箋 というテーマで, クラウド上でデータ基盤を構築する際のサービスの選び方 (データ基盤に限らず)クラウド料金の基本的な考え方 をGoogle

                                                              データ基盤にありがちな「何を使って作ればよいか?」という問いに対する処方箋を用意してみました. - Lean Baseball
                                                            • サーバーサイドエンジニアとして2020年に使った技術 | うなすけとあれこれ

                                                              2020年のフロントエンドエンジニアの技術スタックの一例 | potato4d D(iary) この記事と、TLで「これのバックエンド版が見たい」という発言に触発されたので書いてみます。口語体と文語体が入り乱れてるのは許してください。 冒頭のグラフはwakatimeで生成した今年1年間のプログラミング言語使用率です。2位はTypeScript、3位はTerraform、4位はYAMLでした。 立場 フリーランスで、主にRailsやAWSを使用しているサービスの運用、開発に関わっています。いくつもの会社を見てきた訳ではなく、数社に深く関わっている1都合上、視野が狭いかもしれません。 公開している成果としては クラウドゲーミング最新開発事例 - #CEDEC2020 - Speaker Deck があります。 長年RubyとRailsを書いてきたので、技術スタックがそのあたりに偏っています。

                                                                サーバーサイドエンジニアとして2020年に使った技術 | うなすけとあれこれ
                                                              • AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい

                                                                前にも似たようなこと書いたなと思ったけどもう一年半も前のことになるのか t-cyrill.hatenablog.jp ご存知の通り昨日 2021/02/19 23:20頃 AWSにて東京リージョンの一つ apne-az1 にて大規模な障害が発生。多くのAWSを利用していたサービスで影響があった。 そんな私はいつものように アラストリリィ アサルトリリィ ラストバレット というゲームを呑気にプレイしていたのだけど、23:25 から緊急メンテに入ってしまった。 どうしたんだろうと思っていたら、社内SlackにてAWSを利用しているサービスがたまに応答しなくなる、Elasticacheが切り替わったなどなどの報告が入り、もしかすると面倒ごとかなと思いながら対応することになった。 起きていたこと 既にAWSからも公開されていることであるが、今回は2019年8月に起きた障害と類似するタイプの障害だっ

                                                                  AWSでAZ障害が起きたので困ったことを書いておく - なんかかきたい
                                                                • AWSコスト削減とリソース管理 | 外道父の匠

                                                                  クラウド使いなエンジニアの皆様、猛暑と円安の中いかがお過ごしですか。上層部からインフラコスト削減を突きつけられてはおりませんでしょうか。 今回はおそらく初めてコスト削減についてAWSを軸に書いていきますが、考え方はどこの環境でも似たりよったりなので何かしらの足しになればと思う次第であります。 目次 長いです。ひきかえしたほうがいいぞ! コミュニティに捧げます AWSの売上 コスト削減とは 三大使命 コスト状況整理 Load Balancer 参考リンク 統合による削減 EC2 Autoscaling 参考リンク 情報整理 古いインスタンスタイプの変更 スケジュールの調整 スポットインスタンスの適用 軽量インスタンスの統合・サーバーレス化 アプリケーション処理の軽減 EC2 EBS EBSは高い 不要EBSを削除・スナップショット化 ボリュームタイプの変更 EC2 AMI NAT Gatew

                                                                    AWSコスト削減とリソース管理 | 外道父の匠
                                                                  • マイクロサービスに次に来るかもしれない言葉について - arclamp

                                                                    2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て

                                                                      マイクロサービスに次に来るかもしれない言葉について - arclamp
                                                                    • SaaS系スタートアップのリアルなAWSアーキテクチャ設計

                                                                      概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel(最近資金調達しました!記事はこちら)で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト(リソース・運用) ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論(アーキ

                                                                        SaaS系スタートアップのリアルなAWSアーキテクチャ設計
                                                                      • スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services

                                                                        AWS Startup ブログ スタートアップのためのコンテナ入門 – Kubernetes 編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 「スタートアップのためのコンテナ入門 – 導入編」「スタートアップためのコンテナ入門 – AWS Fargate 編」という記事を公開してきましたが、Kubernetes に興味があるスタートアップも多いのではないでしょうか。今回は Kubernetes にフォーカスしてお話しします。 なお Kubernetes 以前に、「そろそろコンテナやった方がいいか?」「なんとなく使い始めたけれどこれでいいのか?」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といった漠然とした課題感をお持ちの方は「スタートアップのためのコンテナ入門 – 導入編」から目を通して頂ければと思います。 目次 Kub

                                                                          スタートアップのためのコンテナ入門 – Kubernetes 編 | Amazon Web Services
                                                                        • WebAPIを構築する際にAPI Gateway+Lambdaを選択するべきか?

                                                                          はじめに このツイートに結構反響があったので、雑になるがとにかく自分の考えをダンプする。もともと書いていた記事はうっかりやらかしてデータロストした、泣きたい。 話をわかりやすくするために、ALB+ECS(Fargate)を使ってWebAPIと対比して説明しているが現実はもっと複雑である。 引用リツイートをもらえた部分などについてもアンサーっぽいことも書いていく。 AWS利用費と人件費の話 AWS上にWebAPIを構築する際に、AWS利用費の削減をモチベーションとしてApiGW+Lambda構成が、採用されることがある。確かにAWS利用費は下がるがApiGW+Lambda構成を設計〜運用するためにはAWSに関する知識の中でもとくに専門的な知識が必要になる。こういった人材を雇用または外部へ発注し続けることは人件費に跳ね返ってくる。 ApiGW+LambdaがWebAPIのための構成として唯一無

                                                                            WebAPIを構築する際にAPI Gateway+Lambdaを選択するべきか?
                                                                          • 踏み台EC2を廃止してSession Manager接続に置き換えました

                                                                            こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet

                                                                              踏み台EC2を廃止してSession Manager接続に置き換えました
                                                                            • 注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

                                                                              公開日 2024/05/28更新日 2024/07/25注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女

                                                                                注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
                                                                              • AWSの膨大な公式情報を一括して爆速検索可能なサイト「AWS Stash」 | DevelopersIO

                                                                                re:Invnetの動画検索でもめちゃくちゃ便利ですが、その他ブログやホワイトペーパーやGitHubも横断検索できるので、是非一度使ってみてください。 「AWSの公式情報ってめっちゃあるやん。これ、どこから検索すりゃいいの?」 2006年にサービスを開始したAWS。その公式情報は膨大かつイベントも数限りなく開催されてきました。 最近のイベントはYoutubeなどにも公開されており、公式情報だけにしぼってそれらを一括で検索するのは、各サイトのRSSフィードを一括購読とかしないかぎり困難でした。 そんな悩みを一発でふっとばすのが、この AWS Stashというサイト。 re:Inventのセッション動画だけではなく、公式ブログやスライド、QuickstartやホワイトペーパーやGitHubまで横断的に爆速で検索可能な素晴らしく便利なサイトなので、まだ未体験の方は是非一度試してみてください。 何

                                                                                  AWSの膨大な公式情報を一括して爆速検索可能なサイト「AWS Stash」 | DevelopersIO
                                                                                • AWS LambdaとDynamoDBがこんなにツライ時代ではない - めもおきば

                                                                                  ありがたいことに、3年前に#ssmjp 2017/06で話したスライド AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp をTwitterで紹介して頂いた*1 ようで、当時から大幅に改善しているところを振り返りたいと思います。あと、ついでに最近やっているAzureに関しても少し触れていきます。 サーバーレスアーキテクチャ #とは 当時はこう説明したのですが、今でもそんなに悪くない表現かなと思います。 書籍は現在「Serverlessを支える技術 第3版」まで出ていますので、BOOTHからどうぞ(隙あらばダイマしていく方針)。 サーバーレス三種の神器 今このスライドを作るなら、認証認可の話を入れるかなと思います。システム内のAWS IAMとクライアント側のCognitoどちらも重要です。 ちなみにAzureを含めておさらいすると、こんな感じの対応になります。 勝

                                                                                    AWS LambdaとDynamoDBがこんなにツライ時代ではない - めもおきば