並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 2855件

新着順 人気順

fargateの検索結果1 - 40 件 / 2855件

  • 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
          • 2018年なぜ私達はコンテナ/Dockerを使うのか | iret.media

            2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で

              2018年なぜ私達はコンテナ/Dockerを使うのか | iret.media
            • Kubernetes、やめました | 外道父の匠

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

                Kubernetes、やめました | 外道父の匠
              • Dockerコンテナ時代の第一章の終わり、そして第二章の展望など - Publickey

                コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。 そうして始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで基盤技術の基本要素がおおむね固まり、一つの区切りがついたように見えます。 そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。 この記事では、Docker登場から現

                  Dockerコンテナ時代の第一章の終わり、そして第二章の展望など - Publickey
                • AWSの新サービス群に対する一行所感 - プログラマでありたい

                  今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな?認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか? 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに(≒一人の人間)が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ

                    AWSの新サービス群に対する一行所感 - プログラマでありたい
                  • 【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
                    • 転職活動の面接でいただいた質問集 - Qiita

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

                        転職活動の面接でいただいた質問集 - Qiita
                      • 転職活動の面接でいただいた質問集 - Qiita

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

                        • 【コンテナ技術入門】コンテナ要素技術をDocker使わずに基礎から手を動かして学べる超有用なテキスト #dockerTokyo | DevelopersIO

                          「Dockerって、結局中でなにやってんの?」 先日、以下のミートアップに参加して、LT登壇してきました。 Docker Meetup Tokyo #31 (初心者歓迎LT祭り+KubeConCN報告) 自分はLTの一番手として、「雰囲気でコンテナ使っている 全ての人が読むべき 「コンテナ技術入門」の紹介」で喋ってきたので、それの登壇報告となります。 「コンテナ技術入門」は、Dockerコマンド一通り使えるようになってきたけど、もっとDockerやコンテナについて深く知っておきたいという方にはむちゃくちゃ有用なコンテンツなので、一度目を通して、実際に手を動かして試してみることをオススメします。 (祭) ∧ ∧ Y  ( ゚Д゚) Φ[_ソ__y_l〉     コンテナマツリダワッショイ |_|_| し'´J 講演概要 当日のセッションスライドはこちら。 この記事では、LTという時間枠の中

                            【コンテナ技術入門】コンテナ要素技術をDocker使わずに基礎から手を動かして学べる超有用なテキスト #dockerTokyo | DevelopersIO
                          • 2018年の最先端バックエンドエンジニアに必要なスキルについて考えてみました。 - Qiita

                            @rana_kualuさんの2018年の最先端バックエンドエンジニアになろうという翻訳記事がとても興味深かったのですが、記事内で提示されているロードマップに関して微妙に違和感を感じる部分もありましたので、 記事に記載されているスキルは現場でどの程度必要なのか 記事に記載されていないが現場において重要なスキルは何か といった辺りを、自分なりの意見を交えてちょっと書き出してみました。 自分をエンジニアとして最先端だとは全く思っていないのですが、最近のバックエンドのトレンドに一応多少なりともきちんとキャッチアップしてるかなとは思うので、若い方や、まだ経験の短いエンジニアの方たちのご参考になりましたら幸いです。 言語 ロードマップに記載されていた言語のうち、私は一応 Elixir Scala Java .NET (C#とVB.NET) Python Ruby PHP TypeScript Gola

                              2018年の最先端バックエンドエンジニアに必要なスキルについて考えてみました。 - Qiita
                            • 達人出版会:技術系電子出版・電子書籍

                              探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う! オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 Pythonではじめるゲーム制作 超入門 知識ゼロからのプログラミング&アルゴリズムと数学 廣瀬 豪 図解 深層学習 数理で理解する基本原理 小池 敦 独習 ガロア理論 新妻 弘 徹底攻略 情報セキュリティマネジメント教科書 令和6年度 瀬戸美月, 齋藤健一 エンジニアが知っておきたい思考の整理術 複雑な情報を【理解する】【伝える】テクニック 開⽶ 瑞浩 エンジニアのためのChatGPT活用入門 AIで作業負担を減らすた

                                達人出版会:技術系電子出版・電子書籍
                              • Amazon ECS でのコンテナデプロイの高速化

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

                                  Amazon ECS でのコンテナデプロイの高速化
                                • [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
                                  • 東京大学の講義「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
                                    • 熱量を失ったサーバーレスという世界(個人の所感) - 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
                                        • タスク管理ツールの理想を追い求めた結果→自分で作った|ガッシー|Repsona

                                          Repsona LLCの@GussieTechです。 タスク管理ツール、情報共有ツール、便利ですね! これまでいろんな仕事で、いろんなツールを使ってきました。それぞれ、特に不自由もなく、乗り換えるほどのモチベーションもなく使い続けていたんですが、不満が全くなかったわけではありませんでした。 ・遅い ・ダサい ・わかりにく ・カンバンがない ・ガントチャートがない ・Wiki的なものがない ・なぜか仕事がうまく進まない ・SNSみたいな感じで、社員がもっと楽しくつながれたらおもしろそう ・スキルがレベルアップしてる様子とか、可視化されたらおもしろそう ・勝手に仕事してくれたりしないかな、AIとかで ・使ってたら無意識にPMBOKみたいになるように、レールが敷かれていると便利な気がする ・(ひどいコメントをしそうになったときに)「言葉にトゲがないですか?」とか、ボットがやんわり教えてくれるとか

                                            タスク管理ツールの理想を追い求めた結果→自分で作った|ガッシー|Repsona
                                          • 「無人化システム」を駆逐する組織マネジメントとエンジニアリング

                                            弊社では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
                                              • 「それコンテナにする意味あんの?」迷える子羊に捧げるコンテナ環境徹底比較 #cmdevio2019 | DevelopersIO

                                                みなさんコンテナを使うことの意味を自信もって答えられるでしょうか? ここ1年ほどコンテナ関連の仕事をメインでやっているハマコーですが、いろんなお客様からこういったお声をいただくことが多くありました。 「それはコンテナ化する意味があるの?」 「こんなコンテナ運用は危ない?」 「ECSの設定とか実際めんどい。docker runじゃだめ?」 「EKSって使えんの?」 そういう声を聴く中で、自分なりの答えを模索していたわけですが、岡山での弊社イベントAWS最新技術の祭典Developers.IO 2019 at 岡山城へ登壇するにあたり、そのあたりのもやもやを自分なりに昇華したのが、本日の内容です。 「このアプリをコンテナ化する意味があるのか、わからない」 「コンテナ化することで余計めんどくさくなった」 「AWSのコンテナサービスの何を使ったら良いのかわからない」 という悩みを抱えている方には、

                                                  「それコンテナにする意味あんの?」迷える子羊に捧げるコンテナ環境徹底比較 #cmdevio2019 | DevelopersIO
                                                • 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コンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
                                                  • スタートアップのためのコンテナ入門 – 導入編 | Amazon Web Services

                                                    AWS Startup ブログ スタートアップのためのコンテナ入門 – 導入編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 今回はコンテナのお話です。今日、多くのスタートアップのお客様が本番環境でコンテナを採用し、ビジネスに活かしております。その一方で、「そろそろコンテナやった方がいいか?」「なんとなく使い始めたけれどこれでいいのか?」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といったご相談も数多く頂いております。 本記事ではコンテナ技術のサービス利用を検討されている方向けに、AWS 上でどうコンテナ化を進めていけばいいのかをお話致します。 目次 コンテナとは コンテナオーケストレーション コンテナ利用時・検討時によくある誤解 コンテナへの移行ステップ コンテナとは まずはじめに改めてコンテナ技術についての復習です。

                                                      スタートアップのためのコンテナ入門 – 導入編 | Amazon Web Services
                                                    • 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の日記
                                                            • 個人で運用するKubernetesクラスタ - k0kubun's blog

                                                              Kubernetesの使用感に興味があってaws-workshop-for-kubernetesというのを先週やり、ちょうどEKSがGAになった直後だったのでEKSが試せたのだけど、まあ最初からマネージドだとあまり面白みがないし金もかかるので、個人のVPSで動かしてた奴を全部Kubernetes上で動かすようにしてみている。 まだ本番で運用した知見みたいなのが貯まってるわけではないのだが、公式のドキュメントを中心に読んでいても単に動かし始める段階で結構ハマって時間を消費したので、これから同じようなことをやろうとしている人向けに備忘録を兼ねて使用感や知見をまとめておくことにした。 Kubernetesは今でもalphaやbetaの機能が多く、今後この記事の内容も古くなることが予想されるので、なるべく公式のドキュメントへのリンクを置くのを意識して書いてある。 構成 現時点で、ConoHaで借り

                                                                個人で運用するKubernetesクラスタ - k0kubun's blog
                                                              • 【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
                                                                  • noteのフロントエンドをNuxt.jsへ刷新します|こんぴゅ|note

                                                                    webサービスのUXを向上させるために、表示速度は非常に大切です。 しかしながら、noteはリリース当初からフロントエンドの実行速度が遅い=表示が遅いという構造的な問題を抱えており、継続率や離脱率など重要指標に悪影響を及ぼすリスクが強くありました。 noteチームはnoteを本格的なメディアプラットフォームへ成長させるスピードを加速していきます。それを踏まえ、手遅れになる前に技術的な負債を解消し、最新のベストプラクティスに沿ったフレームワークに移行することで、高性能なサービスを提供する基盤を作っていくという決断をしました。 本ポストでは、移行プロジェクトの技術的背景や移行手順を説明します。また、途中成果のデモをUPしているのでご紹介します。 技術的な背景noteの現在のフロントエンドはAngular.js 1系で構築されたSPAです。Angular 1系はかなり複雑なUIでも簡単に構築でき

                                                                      noteのフロントエンドをNuxt.jsへ刷新します|こんぴゅ|note
                                                                    • 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でバッチ処理を実装する際の選択肢とサービス比較
                                                                      • 6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 - データエンジニアの酩酊日記

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

                                                                          6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 - データエンジニアの酩酊日記
                                                                        • いま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年末)
                                                                          • データ基盤にありがちな「何を使って作ればよいか?」という問いに対する処方箋を用意してみました. - 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障害が起きたので困ったことを書いておく - なんかかきたい
                                                                                • ソーシャルゲーム サーバーアーキテクチャ選定 | GREE Engineering

                                                                                  ※Read / Write のレスポンスタイムは大まかに計測した値のため適切な設定ができていない場合もあることをご了承ください MySQL 信頼と実績のあるRDBMS。新規タイトルの場合AWSではAurora、GCPではCloud SQLを利用することで運用の手間をある程度減らすことができる。分散システムではないため1クラスタでの書込性能には限界があり、ソーシャルゲームのように大規模なwrite処理がある用途では水平/垂直分割が必要になり、そのための設計とコーディングが煩雑になりがちである。またインスタンスのスケールアップ・ダウンで対応しきれない場合のクラスタの分割・統合のオペレーションは複雑なものになる。 スケールアップ・ダウンやnodeのメンテナンスなどでMaster nodeを切替える際には不通時間が発生してしまうため、安全のためゲーム自体をメンテナンス状態にする必要が発生する。 ※

                                                                                    ソーシャルゲーム サーバーアーキテクチャ選定 | GREE Engineering