並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 157件

新着順 人気順

ECRの検索結果1 - 40 件 / 157件

  • 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コンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
    • システムをVMからコンテナに移行して、結局VMに戻した話 - MonotaRO Tech Blog

      こんにちは、モノタロウ コアシステムエンジニアリング部門 配送ドメイングループの安見です。 この記事では私が関わっていた社内システムを仮想サーバ(AWS EC2)からコンテナに移行した後にコンテナをやめて仮想サーバに戻した話をご紹介します。 諸説明 コンテナ移行について コンテナ化対象システムについて 直面した様々な問題 リリース後の多数の残課題 展開する機能の数が多すぎる コンテナ化のメリットが薄かった なぜこうなったか よかったこと まとめ 追記: 現在なら... 諸説明 コンテナ移行について システムのコンテナ移行とは、アプリケーションやサービスを動作させるための必要なすべての環境を、一つの「コンテナ」としてパッケージ化して動作できるようにすることです。これにより、アプリケーションは他のシステムと独立して実行され障害分離ができたり、環境の違いによる影響を受けにくくなるため移植性が向上

        システムをVMからコンテナに移行して、結局VMに戻した話 - MonotaRO Tech Blog
      • NATゲートウェイの通信内容を調査して対策し、コストを約60%削減した話 - ZOZO TECH BLOG

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

          NATゲートウェイの通信内容を調査して対策し、コストを約60%削減した話 - ZOZO TECH BLOG
        • ジュニアエンジニアを脱却するための「コンテナ流儀」 - Uzabase for Engineers

          こんにちは。ソーシャル経済メディア「NewsPicks」で検索システムを開発しております崔(ちぇ)です。 この記事は、 NewsPicks Advent Calendar 2023 の23日目の記事になります。 qiita.com 昨日ははぐっさんによる「SwiftUIのKeyframeAnimatorでちょっとしたカードアニメーション 〜猫の手を添えて〜」でした! はじめに コンテナ流儀: 必要最低限のものだけで運用する Point1)レイヤーは少ないほどいい TIP:ベースイメージを作る Point2)不要なパッケージをインストールしない Point3)いつ再起動してもいいコンテナを作る Point4)独立したアプリケーションにする TIP:複数のプロセスを実行したい場合もある TIP:環境変数を積極的に使う Point5)フォアグラウンドで実行する 終わりに まとめ 感想 告知 はじ

            ジュニアエンジニアを脱却するための「コンテナ流儀」 - Uzabase for Engineers
          • ついに最強のCI/CDが完成した 〜巨大リポジトリで各チームが独立して・安全に・高速にリリースする〜 - ZOZO TECH BLOG

            こんにちは。SRE部の巣立(@ksudate)です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー

              ついに最強のCI/CDが完成した 〜巨大リポジトリで各チームが独立して・安全に・高速にリリースする〜 - ZOZO TECH BLOG
            • コンテナのベストプラクティスに対しておこがましくも言ってみる - Qiita

              最近実際に開発現場にコンテナを導入してきた経験から、公式ドキュメントに記載されているベストプラクティスに実際どうなんだということを言ってみようと思います。公式に書いてあることを間違ってると指摘という意図はありません 発言は個人の見解に基づくものであり、所属組織を代表するものではありません。 2023/12/3更新: 燃えかけてるのでタイトルを変えました。 補足: こちらの環境は下記を想定しています。 Java CICD/本番環境イントラネット内に整備 WF開発 マルチステージ・ビルドを使う マルチステージビルドの目的 公式ドキュメントには、下記のように記載があります。 マルチステージ・ビルド は、中間レイヤとイメージの数を減らすのに苦労しなくても、最終イメージの容量を大幅に減少できます。 つまり、最終イメージの容量を減らすことが目的であって、その一つの手段としてマルチステージビルドを進めて

                コンテナのベストプラクティスに対しておこがましくも言ってみる - Qiita
              • 『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ!

                『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本? GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/

                  『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ!
                • 円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します - カミナシ エンジニアブログ

                  こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは、クラウドインフラストラクチャに AWS を採用していますが、昨今の円安を受けて円換算での請求額は右肩上がりで増え続けています。サービスの規模や特性に関わらず、パブリッククラウドを利用する多くの日本企業で頭痛の種になっているのではないでしょうか。 円安になる前から継続的にコスト最適化には取り組んできましたが、クイックウィンで実施できるものはやり尽くしており手詰まり感がありました。しかし、我々スタートアップにおいて適正なコストに抑えることはランウェイ(キャッシュ不足に陥るまでの残存期間)を伸ばす意味でも重要なため、現状に甘んじることなく次の最適化ポイントを探していました。 Arm アーキテクチャ移行によるコスト最適化への期待値 AWS は Arm ベースの Graviton プロセッサを開発しており、

                    円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します - カミナシ エンジニアブログ
                  • AWS LambdaをDocker化する際の注意点と学びの備忘録 - Qiita

                    はじめに AWS Lambdaを使ってデプロイするときに、 Dockerイメージを使って、デプロイしたいケースがありました。 すでに、動いているLambdaをLambda Dockerへ変更する際に、 つまずきポイントがあったので、備忘録として、残しておきます Lambdaでコンテナイメージを利用とは? Lambdaには、通常のLambda(ソースコードのみを記述するタイプ)と Dockerイメージを利用するパターンが存在する ※Dockerイメージは、ECRから参照し、Lambda上で実行が出来る なぜDockerイメージを使うのか? 通常のLambdaとLambda Dockerには、仕様の一部に違う部分が存在している 今回、Lambda Dockerを利用したいと考えたのは、 通常のLambdaよりも、大きいパッケージを展開できる為 ●Lambda 50 MB (圧縮、直接アップロー

                      AWS LambdaをDocker化する際の注意点と学びの備忘録 - Qiita
                    • LambdaでWEBアプリケーションをホストしたい - NRIネットコムBlog

                      本記事は AWSアワード記念!夏のアドベントカレンダー 18日目の記事です。 🎆🏆 17日目 ▶▶ 本記事 ▶▶ 19日目 🏆🎆 はじめに クラウド事業推進部の望月です。NRIネットコムでクラウドエンジニアをしています。 主にネットワーク領域を得意としています。 この度、2024 Japan AWS Top Engineersと、昨年に続き2024 Japan AWS All Certifications Engineersに選出いただきました。 Top Engineersについては、何が評価されて選ばれたのか全く分かりませんが、応募はしてみるものです。 Network領域で応募したもののService領域での選出だったので、狭き門なのですね。。 再流行しているコロナに見事に罹患しつつも、「AWSアワード記念!夏のアドベントカレンダー」の18日目を担当します。 先に結論 Lambd

                        LambdaでWEBアプリケーションをホストしたい - NRIネットコムBlog
                      • コスト最適化目的で個人 AWS アカウントの整理をした

                        ここしばらく円安が続いているのと、結局自宅サーバのおもりがへたっぴで崩壊し続けている関係で EC2 とかばんばか使っていたら日本円コストが嵩んでしまっていた。2024/2 から Public IPv4 Address 課金も開始されるのもきっかけ。 なんとかすべく 2023 年末に休みを取って大整理をやった。サボっていたけどこのままだとさすがにキツいなと思って基本的にはしょうもない整理です。基本的には homelab として意図的に色々あそべるようにしていたのを止めたりとかになる。ご笑覧ください。 どんなもん 月間コスト 378 USD (2023/8) → 153 USD (2023/12), without tax 日本円コスト 59,099 JPY → 24,583 JPY/mo, with tax 内訳 (USD); EC2-Instances: 140.92 → 61.27 S3

                        • OIDCって何なんだー?から、実際に使うまで - BASEプロダクトチームブログ

                          ごあいさつ はじめましての人ははじめまして、こんにちは!BASE BANK Divisionのフロントエンドエンジニアのがっちゃん( @gatchan0807 )です。 今回は、ここ数ヶ月の間にOIDC(OpenID Connect)という技術を使った開発を複数行い、この技術の概観を理解することができたので、OIDCの技術概要に触れつつBASE BANKの中でどのように使ったのかをご紹介しようと思います。 OIDCとは何なのか このパートでは、まずOIDCという技術について概要を紹介します。いくつかのWebページに記載されていた内容を参考にしてまとめさせて頂いているので、記事の最後に参照元のリンクを記載しておきます。 また、OIDCをはじめとした認証・認可の仕組みには様々な用語があり、自分自身も「調べれば調べるほど知らない用語が増えて、どんどんわからなくなってきた…」という経験をしたので、

                            OIDCって何なんだー?から、実際に使うまで - BASEプロダクトチームブログ
                          • Aurora MySQL におけるロック競合(ブロッキング)の原因を事後調査できる仕組みを作った話

                            こんにちは。 DBRE チーム所属の @p2sk です。 DBRE(Database Reliability Engineering)チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE チーム発足の背景やチームの役割については「KTC における DBRE の必要性」というテックブログをご覧ください。 本記事では、Aurora MySQL でロック競合(ブロッキング)起因のタイムアウトエラーが発生した際に根本原因を特定することができなかったので、原因を後追いするために必要な情報を定期的に収集する仕組みを構築した

                            • モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog

                              こんにちは。モノタロウのTechBlog編集チームです。 モノタロウではECサイトでのお客様体験の向上を目指して、日々改善に取り組んでいます。 商品の出荷目安などの出荷関連情報は重要な要素の1つになります。 今回は、出荷関連情報の正確性を改善するとともにシステムの変更容易性を向上させるためにマイクロサービス化に取り組んだ活動をインタビューしました。 自己紹介 納期表示を高度化する サプライヤ在庫連携機能開発のつらみ AVLのマイクロサービス開発のすすめ方 リリース・監視・その後の展開 おわりに 今回インタビューしたみなさん 自己紹介 山崎 章裕 ECシステムエンジニアリング部門 開発生産性グループ、プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム兼務 2019年8月に入社し、主にECサイトの注文・配送周りのプロジェクトにテックリードとして関わる。またECサイ

                                モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog
                              • 2023年のSREチームのAWSコスト削減を振り返る - Uzabase for Engineers

                                概要 全般 何はともあれコストタグ Cost Explorer でリソース別にコストを見よう IaC化しよう QuickSight も使おう 稼働時間対応する際はマスタカレンダを用意したい コンピューティング、コンテナ関連 EC2 定時バッチはマネージド化しよう EBS, Snapshot, AMI, EIP を消す ECS Container Insights の有効/無効を使い分けよう 何でも Fargate を選択すれば良いわけではない Fargate スポットを活用しよう Lambda Graviton対応しよう ECR イメージサイズを抑えよう ライフサイクルポリシーを設定しよう ネットワーキング VPC VPCエンドポイント入れ忘れに注意 VPC Flow Logs のS3バケット設定に注意しよう ストレージ系 RDS スロークエリ出てないかAPMを使って確認 DynamoDB

                                  2023年のSREチームのAWSコスト削減を振り返る - Uzabase for Engineers
                                • 【2024年】AWS全サービスまとめ | DevelopersIO

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

                                    【2024年】AWS全サービスまとめ | DevelopersIO
                                  • ChatOpsによる運用作業の自動化 - ZOZO TECH BLOG

                                    はじめに こんにちは、技術本部SRE部カート決済SREブロックの遠藤・金田です。 普段はSREとしてZOZOTOWNのカート決済機能のリプレイスや運用を担当しています。本記事では自作のコマンドラインツールをSlack + AWS Chatbot + AWS Lambdaを使用してChatOps化した事例をご紹介します。「日々の運用業務をコマンドラインツールを実装して効率化したものの今ひとつ広まらない」「非エンジニアにも使えるようにしたい」と考えている方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 ChatOpsとは AWS ChatBotとは 構成 AWS ChatBot チャットツール側の設定 Slack Workflow Lambda 実装のポイント ChatBotのアクセス制御 User Roleの運用方法 ガードレールポリシー コマンドラインツールのLambda関数化

                                      ChatOpsによる運用作業の自動化 - ZOZO TECH BLOG
                                    • [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
                                      • AWS ECS で実現するBlue/Green Deployment:運用を見据えたCDK実装例 - Techtouch Developers Blog

                                        始めに 対象者 作成するアプリケーション構成 運用を見据えた構成とは 構成概要 各スタックの説明 ① SampleInfrastructureStack ② SampleContainerRepositoryStack ③ SampleTaskDefinitionStack ④ SampleServiceStack ⑤ SampleServicePreferenceStack ⑥ SamplePipelineStack 動作確認 正常にデプロイが完了する場合のCodeDeployの挙動 ロールバックが発生する場合のCodeDeployの動作 終わりに 始めに バックエンドの com です。 テックタッチでは Blue Green Deployment 構成の ECS クラスタを、AWS CDK によるコードで管理しながら本番運用で使っています。 ECS Blue Green Deploym

                                          AWS ECS で実現するBlue/Green Deployment:運用を見据えたCDK実装例 - Techtouch Developers Blog
                                        • SSMって20種類あんねん 〜Run Commandで定期バッチを起動する〜 - NRIネットコムBlog

                                          どうも。小林です。 みなさん、自動化してますか? 私の課では特定の顧客のシステムを多数運用しています。 かなり多くのシステムがあり、顧客側の担当者も異なるため、弊社側でも複数のチームを組んで手分けしてシステムを担当しています。 チームも顧客担当者も異なるとなれば、当然運用のやり方はシステムごとに変わってきます。その一方で統一できる部分は統一しておかないと全体の統制は効きづらくなってしまいます。 そこで「標準化チーム」を発足し、チーム間で共用するシステムのアカウント管理やその申請ルール、顧客報告やメンバーの勤怠管理といったものの標準化を進めています。 標準化の恩恵のひとつとして、「作業が単純化できて自動化しやすくなる」という点が挙げられます。 例えばアカウント発行の申請フォーマットを統一すると、「フォーマットにしたがって記載されたテキストをバッチに読み込ませてアカウントを自動的に発行する」と

                                            SSMって20種類あんねん 〜Run Commandで定期バッチを起動する〜 - NRIネットコムBlog
                                          • AWSコスト削減の一環でecrmを使ってECRの不要イメージを削除した話 - コネヒト開発者ブログ

                                            こんにちは、コネヒト プラットフォームグループの@yosshiです。 昨今、円安の進行によりAWSのコスト増が無視できない状況となっています。 このような状況下で、コスト削減関連のイベントに注目が集まるなど、コスト削減への関心が徐々に高まってきているように感じます。 弊社でもさまざまな方法でコスト削減施策を進めており、今回はその一環で「ecrm」というツールを使用しECRイメージを削除した話をしたいと思います。 弊社では、コンテナのオーケストレーションにAmazon ECSを主に使用しています。 ECSにタスクをデプロイする場合は、イメージをビルドした上でAmazon ECRにpushし、そのECRのイメージを使用しタスクを起動しています。 ECRはイメージが増えれば増えるほど、容量に応じてコストがかかるので、この機会に対応したいと考えていました。 ECRで発生するコスト ECRではデータ

                                              AWSコスト削減の一環でecrmを使ってECRの不要イメージを削除した話 - コネヒト開発者ブログ
                                            • AWS 認定トレーニング「Advanced Architecting on AWS」を受講してみた | DevelopersIO

                                              お疲れ様です。AWS 事業本部のヒラネです。 AWS 認定トレーニング「Advanced Architecting on AWS」を受講してきたので内容のご紹介や感想をお伝えしたいと思います。 お疲れ様です。AWS 事業本部の平根です。 AWS 認定トレーニング「Advanced Architecting on AWS」を受講してきたので内容のご紹介や感想をお伝えしたいと思います。 AWS トレーニングとは AWS トレーニングとは、AWS の利用方法の知識とスキルを身に付けるための公式教育プログラムです。 クラスメソッドのメンバーズプレミアムサービスにご加入いただいているお客様の場合は、 特別割引価格で受講いただけます! 提供トレーニングの詳細やお申込みは以下 URL をご参照ください。 今回は、トレーニングの中でも「Advanced Architecting on AWS」を受講しまし

                                                AWS 認定トレーニング「Advanced Architecting on AWS」を受講してみた | DevelopersIO
                                              • VPC Flow LogsをAthena + QuickSightで
分析してデータ転送料金の内訳を調査する 〜 実践的なコスト最適化の洞察 〜 - Uzabase for Engineers

                                                こんにちは。ソーシャル経済メディア NewsPicksのSREチームで仕事をしている安藤です。 NewsPicks Advent Calendar 2023 の1日目ということで、日常の業務風景から軽いコスト最適化TIPSをご紹介します。 qiita.com AWSコストを最適化したいよぉ〜 NewsPicksはおかげさまでサービス10周年を迎え、ユーザー数も事業も伸びておりますが、 事業の成長やエンジニア組織の拡大に比例してAWSコストが増え、円安でさらに日本円での負担が増え、となると事業の利益率にも少なからず影響がでます。 私が所属するSREチームでは、「売上に対するAWSコストの割合は、規模が拡大するほど減っていくべき」という考えを持っており、 積極的にAWSサービスの使い方を見直して毎年コストを削っていくつもりで仕事をしています。 AWSが提唱するCloud Financial M

                                                  VPC Flow LogsをAthena + QuickSightで
分析してデータ転送料金の内訳を調査する 〜 実践的なコスト最適化の洞察 〜 - Uzabase for Engineers
                                                • EKSでKubernetes DaemonSetを用いたロギング:Fluent-bitの運用とトラブル事例 - MonotaRO Tech Blog

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

                                                    EKSでKubernetes DaemonSetを用いたロギング:Fluent-bitの運用とトラブル事例 - MonotaRO Tech Blog
                                                  • SREエンジニアがヘルプデスク体制を作ってみた話 - ぐるなびをちょっと良くするエンジニアブログ

                                                    こんにちは。データ・AI戦略部 SREチームの小野です。2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、SRE業務の一環で組織作りに挑戦しています。SREエンジニアの責務は自社サービスを安定稼働させ障害に強い基盤を作ることであり、どちらかというと「システム」に焦点が置かれがちです。しかし、個人的にはシステムを運用するメンバーのマネジメント(ピープルマネジメント)を含めた組織作りも重要だと考えています。なぜなら、どれだけ最先端で素晴らしいシステムを構築してもそれを運用するメンバーの行動次第では、障害につながる恐れがあるためです。 私にとってのSREは組織作りにおける文化のようなものであり、「SRE(文化)を組織にインストールする」気概で色々と挑戦しています。 今回は、その挑戦の一つとして「ヘルプデスク体制を構築した話」をお伝えしたいと思

                                                      SREエンジニアがヘルプデスク体制を作ってみた話 - ぐるなびをちょっと良くするエンジニアブログ
                                                    • オフェンシブ視点による Cloud Security 入門 ~AWS 編~ - blog of morioka12

                                                      1. 始めに こんにちは、morioka12 です。 本稿では、AWS 環境における攻撃者のオフェンシブな視点で Cloud Security の入門として紹介します。 1. 始めに 免責事項 想定読者 2. クラウドにおける脅威 クラウドの重大セキュリティ脅威 11の悪質な脅威 クラウドサービス利用に関連するリスク Top 10 AWS セキュリティ構成ミス Top 10 3. AWS 環境における攻撃者の観点 3.1 AWS 環境の外部からの観点 3.2 AWS 環境の内部からの観点 4. MITRE ATT&CK Framework for Cloud (IaaS) 4.1 初期アクセス (Initial Access) 4.2 実行 (Execution) 4.3 永続化 (Persistence) 4.4 権限昇格 (Privilege Escalation) 4.5 防御回避

                                                        オフェンシブ視点による Cloud Security 入門 ~AWS 編~ - blog of morioka12
                                                      • GoでKubernetesクラスター上にモックリソースをサクッと構築するOSSを開発しました - ZOZO TECH BLOG

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

                                                          GoでKubernetesクラスター上にモックリソースをサクッと構築するOSSを開発しました - ZOZO TECH BLOG
                                                        • CI/CDとAWS Batchが体系的に学べるハンズオンをやってみた | DevelopersIO

                                                          はじめに こんにちは、AWS事業本部コンサルティング部の酒井です。 直近で携わるプロジェクトでAWS Batchが使われているのですが、経験がなかったので概要を把握するべくハンズオンをやってみました。 同時に CI/CDも触れる「CI/CD for AWS Batch Workshop」というハンズオンがあったので、紹介したいと思います。 ハンズオンに記載のなかった削除リソースも一覧化しているので、参考にしてみてください。 概要 ハンズオンでは以下のことが学べました。 Cloud9 ECR CodeCommit CodeBuild CodePipeline AWS Batch 基本的なGitコマンド 基本的なDockerコマンド やってみる 1. 事前準備 Adminのロールは作成済みなのでスキップし、Cloud9を作成。 yamlファイルをダウンロードし、スタックを作成。 2. 手動デプ

                                                            CI/CDとAWS Batchが体系的に学べるハンズオンをやってみた | DevelopersIO
                                                          • ベストなCDK for Terraform(CDKTF)のディレクトリ構成を探る

                                                            最近関わっているプロジェクトでは、大きなアプリケーションのリアーキテクチャを行っています。 そこではフルスクラッチでインフラの構成を書き直す機会がありました。 そのプロジェクトは社内では比較的複雑な構成になっていて、リアーキテクチャにあたっては、アプリケーション特有の事情により、考慮すべきポイントや難度が高いところがたくさんありました。 具体的には、複数のマイクロサービス間の協調性や独立性とそれに付随する認証/認可、クライアント証明書(mTLS認証)の管理、歴史的経緯による複雑性を正すためのawsアカウント移行などなど。 それらは別の機会で語る(or 同僚の誰かが語ってくれることに期待したい)として、この記事ではインフラをフルスクラッチで書き直すにあたって選択したCDKTFについて、紆余曲折を経つつも最終的に採用したディレクトリ構成について書きたいと思います。 タイトルには「ベストな」とあ

                                                              ベストなCDK for Terraform(CDKTF)のディレクトリ構成を探る
                                                            • 障害への不安をぶっ壊す!カオスエンジニアリングを運用しシステムとチームの耐障害性を高める - ZOZO TECH BLOG

                                                              はじめに こんにちは、計測プラットフォーム開発本部SREブロックの山本です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。 我々のチームは、複数サービスを運用する中で障害対応の経験不足や知見共有の難しさといった課題に直面していました。そこで、半年ほど前にカオスエンジニアリングの導入を開始しました。 本記事では、カオスエンジニアリングを一過性のものではなくチームの文化として根付かせ、継続的な改善サイクルを生み出すための導入から運用まで、我々のチームでの実践から得られた具体的な方法をお伝えします。 これからカオスエンジニアリングを始めようとしている方はもちろん、すでに導入しているものの効果的な運用に悩んでいる方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 カオスエンジニアリング導入の流れ 1. 目標とKPIの設定 1.1 目標

                                                                障害への不安をぶっ壊す!カオスエンジニアリングを運用しシステムとチームの耐障害性を高める - ZOZO TECH BLOG
                                                              • 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
                                                                • [待望] CloudShell で Docker が利用可能になりました | DevelopersIO

                                                                  待望の CloudShell で Docker が使えるようになりました。今回は簡単に全体像まとめて、コンテナイメージをビルドしてみました。 こんにちは! AWS 事業本部コンサルティング部のたかくに(@takakuni_) です。 タイトルの通りで CloudShell で docker コマンドが使えるようになってました。 今まではどうだったか 今まで、 CloudShell では Docker がサポートされておらず、コンテナイメージのビルド等が CloudShell 上で行えませんでした。 過去の Stack Overflow を確認するに、インストールはできるが、デーモンの起動ができなかったようです。 [cloudshell-user@ip-10-0-73-203 ~]$ docker images Cannot connect to the Docker daemon at u

                                                                    [待望] CloudShell で Docker が利用可能になりました | DevelopersIO
                                                                  • 電子レジスターおよび店舗向けサービスの提供事業終了について - お知らせ | CASIO

                                                                    <a href=\"https://www.casio.com/jp/casio-id/\">CASIO IDで新しい体験を</a></p>\r\n"}}" id="text-736e2c2f04" class="cmp-text"> CASIO IDで新しい体験を 平素より弊社の電子レジスターおよび店舗向けサービスをご愛顧いただき誠にありがとうございます。<br>\r\nこの度、昨今の製造・物流コスト高騰や市場環境の変化などを受け、電子レジスターおよび店舗向けサービスの提供事業を下記の通り順次終了することとなりました。<br>\r\nご利用中の電子レジスターの保守サポートおよび各種サービスの提供は今後も下記日程まで継続いたしますが、終了時期につきましてあらかじめご了承賜りますようお願い申し上げます。</p>\r\n"}}" id="text-c533b6a173" class="cmp-

                                                                      電子レジスターおよび店舗向けサービスの提供事業終了について - お知らせ | CASIO
                                                                    • 【10周年前祝い】歴史・年表でみるAWSサービス(AWS Lambda編) -機能一覧・概要・アップデートのまとめ・入門- - NRIネットコムBlog

                                                                      小西秀和です。 「歴史・年表でみるAWS全サービス一覧 -アナウンス日、General Availability(GA)、AWSサービス概要のまとめ-」から始まった、AWSサービスを歴史・年表から機能を洗い出してまとめるシリーズの第8弾です(過去、Amazon S3、AWS Systems Manager、Amazon Route 53、Amazon EventBridge、AWS KMS、Amazon SQSについて書きました)。 今回は2014年11月にアナウンスされたサーバーレスでフルマネージドなコード実行サービスを提供するAWS Lambdaについて歴史年表を作成してみました。 今年2024年11月にはAWS Lambdaがアナウンスから10周年を迎えるということで、かなり早めではありますが前祝いという意味も含めて、この記事を書きました。 今回もAWS Lambdaの誕生から機能追

                                                                        【10周年前祝い】歴史・年表でみるAWSサービス(AWS Lambda編) -機能一覧・概要・アップデートのまとめ・入門- - NRIネットコムBlog
                                                                      • Renovate の Best Practices から学ぶ依存関係管理の考え方

                                                                        Renovateはプロジェクトの依存関係の更新を自動化するツールです。 npmライブラリやGitHub Actions、Dockerイメージのバージョンなどを監視し、ライブラリアップデート用のPRの作成を行います。 Renovateは豊富な構文から柔軟な設定ができますが、プリセットと呼ばれるカスタマイズされた設定集を利用することもできます。 その中でconfig:best-practicesというRenovateが考えるベストプラクティスのプリセットが用意されています。 このプリセットを読み解くことで、Renovateがどのようにライブラリのバージョンを指定し運用するべきか知ることができます。 この記事ではconfig:best-practicesの設定を読み解き、どのようにライブラリの依存関係を扱うかを考えていきます。 config:best-practice で設定されている項目 執筆

                                                                          Renovate の Best Practices から学ぶ依存関係管理の考え方
                                                                        • terrraformを使ったGoのLambdaの管理 - カンムテックブログ

                                                                          SREの菅原です。 カンムのサービスはWebサービス・バッチ処理なども含めて基本的にはECS上で動かしているのですが、簡単なバッチ処理はLambda+EventBridge Schedulerの組み合わせで動かすこともあります。 LambdaはECSに比べてDockerイメージのビルドやECRの準備が不要で作成の手間が少ないのですが、terraformでデプロイまで含めて管理しようとすると少し問題がありました。 terraformでのLambdaのデプロイの問題点 例えば以下のような構成のNode.jsのLambdaをデプロイする場合 / ├── lambda.tf └── lambda ├── app.js ├── package-lock.json └── package.json // app.js const util = require("util"); const gis =

                                                                            terrraformを使ったGoのLambdaの管理 - カンムテックブログ
                                                                          • 円安に負けない!共通バックエンドAPIサーバーARM対応プロジェクト - Uzabase for Engineers

                                                                            こんにちは。ソーシャル経済メディア「NewsPicks」のSREチームの飯野です。 SREでは2023年から円安に負けないコスト削減を継続して行なっていますが、最近は圧倒的な円安におされ気味です。 2024年1月-6月の間に141→161円の変動はちょっと厳しすぎますよね。 今回は2024年1月から3月にかけて行なったNewsPicksの共通バックエンドAPIサーバーのARM対応プロジェクトについて話したいと思います。 ARM対応はコスト削減を目的とした施策です。適用範囲の見誤りがあり、当初の想定ほど大きなコスト削減は実現できませんでしたが、活発に変更が行われるプロダクトに段階的に変更を加えてリリースすることができました。 ARM対応をするにあたり、何を考えてどの順番で着手したかという情報は、今後ARM対応を行う開発者に参考になりそうなので紹介します。 ARM対応計画 ARMのコンテナイメ

                                                                              円安に負けない!共通バックエンドAPIサーバーARM対応プロジェクト - Uzabase for Engineers
                                                                            • AWS COST CUT FIGHT 回答を作ってみました - 弁護士ドットコム株式会社 Creators’ blog

                                                                              概要 10月5日(土)に開催されたYAPC::Hakodate 2024 で「AWS COST CUT FIGHT」という株式会社DELTA様のイベントがありました*1。 その中で弊社SREが2000$越えのコスト削減を達成しました。 むずかった😇 月間$ 2,150のAWSコスト削減に成功しました! あなたはいくら削減できる!? コスト削減クイズにチャレンジ! presented by 株式会社DELTA https://t.co/CQyjt4khLM #yapcjapan— nakamura (@__namakura) 2024年10月5日 と思ったらついに2000ドルの壁を超えた猛者が!#yapcjapan https://t.co/urqqE3jekh pic.twitter.com/VZStS3paEj— Keisuke Nishitani (@Keisuke69) 2024年

                                                                                AWS COST CUT FIGHT 回答を作ってみました - 弁護士ドットコム株式会社 Creators’ blog
                                                                              • 【総まとめ】GuardDutyによるコンテナランタイム脅威検知の注意事項と設定手順と検出の様子 #AWSreInvent | DevelopersIO

                                                                                AWSマネージドサービスGuardDutyによる待望のコンテナランタイム脅威検知。その検知内容と設定上の注意事項、検出の様子をまとめてお届けします。 「ECSのランタイム脅威検知って、商用製品必須だよね。どれにすっかなぁ。結構高いよね」 「1年前の予告を経て、よーーーやくAWSマネージドなやつがGAされましたよ」 去年のre:Invent2022においてKeynote中に予告だけされていたコンテナ環境のランタイム検知(【速報】GuardDutyによるコンテナランタイムの脅威検知サービスが発表されました!)。 先日のre:Invent 2023のアップデートにより、待望のECSにおけるランタイム検知が、GuardDutyで実現できるようになりました!!もともとEKSにおけるランタイム検知は提供されていましたが、それがECSにも拡張されたアップデートです。 これまでAWSのECSにおいてランタ

                                                                                  【総まとめ】GuardDutyによるコンテナランタイム脅威検知の注意事項と設定手順と検出の様子 #AWSreInvent | DevelopersIO
                                                                                • ECS FargateでSeleniumを実行する

                                                                                  はじめに こんにちは、GMOソリューションパートナーのTKです。 当社には、AWSの学習用のアカウントがあります。 今回はそれを活用して、ローカルのdocker環境上で動かしていたSeleniumを ECSのFargateで動作させてみることにしました。 構成 root ├ python │ └ Dockerfile │ └ requirements.txt │ └ script.py ├ selenium │ └ Dockerfile └ docker-compose.yml コード pythonディレクトリ配下 FROM python:3.12 ENV TZ Asia/Tokyo RUN apt-get update && \ apt-get install -y sudo vim && \ apt-get clean COPY ./ /app RUN pip install -r /

                                                                                    ECS FargateでSeleniumを実行する