はじめにクレディセゾンに来てちょうど５年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない！」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません！ 2019年：ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか？」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ
システムをVMからコンテナに移行して、結局VMに戻した話 - MonotaRO Tech Blog
こんにちは、モノタロウ コアシステムエンジニアリング部門 配送ドメイングループの安見です。 この記事では私が関わっていた社内システムを仮想サーバ(AWS EC2)からコンテナに移行した後にコンテナをやめて仮想サーバに戻した話をご紹介します。 諸説明 コンテナ移行について コンテナ化対象システムについて 直面した様々な問題 リリース後の多数の残課題 展開する機能の数が多すぎる コンテナ化のメリットが薄かった なぜこうなったか よかったこと まとめ 追記： 現在なら... 諸説明 コンテナ移行について システムのコンテナ移行とは、アプリケーションやサービスを動作させるための必要なすべての環境を、一つの「コンテナ」としてパッケージ化して動作できるようにすることです。これにより、アプリケーションは他のシステムと独立して実行され障害分離ができたり、環境の違いによる影響を受けにくくなるため移植性が向上
5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、
はじめに こんにちは。WEARバックエンド部SREブロックの春日です。普段はWEARというサービスのSREとして開発・運用に携わっています。本記事では、約60％のコスト削減に成功したNATゲートウェイの通信内容の調査方法と通信量の削減方法についてご紹介します。 目次 はじめに 目次 背景 コストの把握 NATゲートウェイの通信内容の把握 CloudWatchメトリクスでの確認 VPCフローログでの確認 リゾルバーでのクエリログでの確認 調査結果をもとにNATゲートウェイ経由での通信量を削減する AWSサービスとの通信 Datadogとの通信 WEARのAPIとの通信 ECRパブリックリポジトリとの通信 結果 まとめ 背景 ZOZOではより効果的な成長を目指してコストの最適化を進めています。コストの増大はサービスの拡大を鈍化させる原因となるため、常に最適な状態に保つことが必要です。WEARで
いわさです。 「Building Multi-Tenant SaaS Architectures」という海外の書籍があります。 著者は Tod Golding さんで、AWS のシニアプリンシパルソリューションアーキテクトの方です。 SaaS on AWS の領域でよく見かける方で、先日もラスベガスの re:Invent 2024 で講演されておりました。 マルチテナント SaaS を構築・運用するためには様々な課題に取り組む必要があるのですが、上記書籍はそれらの実用的なテクニック・戦略・パターンを解説したものです。 Building Multi-Tenant SaaS Architectures の日本語翻訳版が出るよ Building Multi-Tenant SaaS Architectures は 2024 年 4 月に発売されたのですが、来月 2025 年 1 月になんとこちらの
マルチテナントSaaSアーキテクチャの構築
TOPICS 発行年月日 2025年01月 PRINT LENGTH 468 ISBN 978-4-8144-0101-7 原書 Building Multi-Tenant SaaS Architectures FORMAT Print PDF SaaS（Software as a Service）とは、ソフトウェアをクラウド環境などでホストし、ユーザーにサービスとして提供する形態のビジネスモデルです。マルチテナントとは、複数のユーザーが同一のリソースを共有するモデルや、それらを統一された体験を通じて管理する仕組みを指します。セキュリティや可用性、運用面などで独自の考慮事項が必要となりますが、インフラストラクチャコストの削減や運用効率の向上が見込めるため、近年その採用件数は右肩上がりに増加しています。本書は、エンジニア向けの本格的なSaaS解説本として、マルチテナントSaaSの概念、実践的
起業なのか請負開発か趣味のプロジェクト（ペットプロジェクト）かによって状況は異なりますが「私のチームの開発者は私１人だけです」という個人開発においても、ADRは有効なツールとなりえます。 ADRとは何か？ ADR（アーキテクチャデシジョンレコード）は、ソフトウェアアーキテクチャにおける重要な設計判断とその根拠、影響、関係する検討事項などを記録した文書です。 一見、現代的な響きですが、その実態はシステム設計ドキュメントの一部です。 "ADR"で検索すると真っ先にヒットするアーキテクチャの入門書『Design It! ―プログラマーのためのアーキテクティング入門』では、ADRは「アーキテクチャ手法に対する開発者寄りのアプローチ」と説明されており、アーキテクトと開発者自身がアーキテクチャに関する意思決定を記録し、共有するための手法として位置づけられています。 アーキテクチャデシジョンレコード（A
多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社会員限定コンテンツ無料登録してアーキテクチャを見る アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー！」やD2C型SaaS「ウラカタ」を始め、1,000万会員/1万施設を超える顧客に複数サービスを提供しています。
社内の基盤を活かして爆速開発を実現するために重視したマイクロサービステンプレートの5つの要点 - MonotaRO Tech Blog
はじめに 転職後の二つの喪失感への対応 所属チームの現状とMonotaROのアプリケーション/サービス共通基盤（所謂プラットフォーム） 所属チームの状況 社内プラットフォームの状況 マイクロサービス開発のためのテンプレートの導入 開発のロケットスタート：テンプレートの早期提供 テンプレート作成の5つの要点 1. ベンダー非依存なObservabilityの実装 2. CI/CDを早期に提供（特にLinterを最初期に） 3. APIプロトコルとして、JSON over HTTPとgRPCの双方をサポート 4. 最低限の薄いフレームワーク 5. セントラルProtobufリポジトリの提供 現在の取り組み (2023年10月以降)と今後の展開 さいごに はじめに はじめまして、MonotaROのCTO-Officeに所属する伊藤と申します。 github.com recruit.monotar
※一番下に追記あり 理由社内政治的に言えば負け組に属するし昇給に期待できないのとメンタル面の複合的な理由で頑張り切れなくて成果も出ずモチベーションが下がってる。 今後のベースアップも望み薄な状況になったので給与同水準で今後頑張れそうなところに入りてぇなぁ。 希望現状と同水準の年収500万、それ以上もらえるのならうれしい。 完全リモートワーク。出向などはなし。 ITSとかのまともな健康保険組合に属している。 スキルセットWeb系といえばWeb系。Androidアプリ開発もやってたけど今はWebの運用保守まわり。 就職して10年くらい流れに身を任せてなぁなぁに過ごしてきたので何も身についてる気がしない。 以下のスキルもだいたいが腰をいれてやろうと思えばできる、なレベル。 ・まぁわかる k8s, Java(SpringBoot), PHP(5.3くらいまでの話) 業務でバックエンド周りの保守を触
メンテナンスコスト削減を実現したOpenTelemetryへの挑戦 ～NTTデータに学ぶ、オブザーバビリティの取り組み～ - Findy Tools
公開日 2024/08/14更新日 2024/08/28メンテナンスコスト削減を実現したOpenTelemetryへの挑戦 ～NTTデータに学ぶ、オブザーバビリティの取り組み～ オブザーバビリティの重要性が高まっている現在、その実現に向けたオープンソースプロジェクトであるOpenTelemetryが注目を集めています。一方、OpenTelemetryの具体的な導入事例やOpenTelemetryを用いたオブザーバビリティの取り組みについては、発信されている情報はまだ多くありません。 そんななか、Findy Toolsでは株式会社NTTデータの取り組みに注目。NTTデータでは、クラウドネイティブ環境やマイクロサービスアーキテクチャの採用増加に伴い、システムが複雑に。この課題に対応するため、OpenTelemetry を軸としたオブザーバビリティの実現に積極的に取り組んでいるといいます。 今回
モバイルゲームの裏側には、最高のプレイ体験を支える高度なインフラ技術があります。 本特集では、「グリー株式会社」「株式会社gumi」「ＫＬａｂ株式会社」「株式会社コロプラ」「株式会社MIXI」の5社のエンジニアの方々にご協力頂き、インフラにおける技術選定のポイントや今後の展望を、アーキテクチャ図と共に解説頂きました。 ※ご紹介は企業名のアルファベット順となっております グリー株式会社 会員限定コンテンツ無料登録してアーキテクチャを見る アーキテクチャ選択の背景や意図 ゲームサービスのクラウドアーキテクチャとして重要な点は、急激な高負荷に対してスケールできることと、サービスのメンテナンス時間を不要にできることの2点でした。そのため、Google Kubernetes EngineとCloud Spannerを主軸に置いた構成となっています。特に、書き込み・読み込みの性能のスケールができ、クラ
福島銀行、勘定系システムをAWS上で国内初稼働
この記事は本多和幸氏と谷川耕一氏によるIT事例メディア「CaseHub.News」に掲載された「福島銀行、勘定系システムをAWS上で国内初稼働 拡張性や柔軟性確保したアーキテクチャに」（10月25日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。 福島銀行は2024年7月、AWS上で稼働する勘定系システムの本番運用を開始した。3カ月が経過した現在、安定稼働を継続しているという。アマゾンウェブサービスジャパンが10月23日に発表した。SBIホールディングスグループ各社がフューチャーアーキテクトと連携して地域金融機関向けに提供するクラウドベースの勘定系システムで、同行が国内で初めて採用した。AWS上で稼働する勘定系システムとしても国内初の事例。 新システムは、コンテナ化されたアプリケーションを運用管理する「Amazon Elastic Kubernetes Servic
N予備校のインフラを Amazon EKS に移行した話 はじめまして。ドワンゴの教育事業で SRE エンジニアをしている西永です。 N予備校 では Kubernetes を採用しています。 これまでは Control Planes 含めすべての構成要素を自前で構築し運用していましたが、様々な問題が発生してきたことから Amazon EKS に移行をおこないました。 この記事では、Amazon EKS への移行に取り組んだ事例にについて紹介します。 なぜ移行したのか Kubernetes のバージョンが古い これまでの構成では Kubernetes のバージョンアップが考慮されておらず、Kubernetes を利用した N予備校の提供開始以降バージョンアップができていない状態でした。 そのためバージョン 1.7 を利用し続けていました。 バージョン 1.7 は 2017 年にリリースされ、
クラウドエンジニアとは この記事ではクラウドエンジニアの定義を「AWS、Google Cloud、Azure 等のクラウド技術をメインに扱うエンジニア」とします。インフラエンジニアから少し領域を狭めたものだと思っていただければ、わかりやすいかと思います。 5選の選定基準 ここで選ぶ5選は SIer 企業所属のクラウドエンジニアである私自身の体験や、スタートアップや事業会社の技術スタック、技術ブログや SNS など、自分なりに調査して選出しました。あくまで私なりに導いた選出であると考えてください。傾向として選出は少し開発分野よりになっています。 各技術において選出したサービス クラウドエンジニアの定義では複数のクラウドをあげていますが、私自身が AWS を扱うことが多いということもあり、クラウドは AWS をメインに選出しました。選出したサービスは一部偏りがあるかもしれませんが、これは本5選
モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス - MonotaRO Tech Blog
こんにちは。モノタロウのTechBlog編集チームです。 モノタロウではECサイトでのお客様体験の向上を目指して、日々改善に取り組んでいます。 商品の出荷目安などの出荷関連情報は重要な要素の1つになります。 今回は、出荷関連情報の正確性を改善するとともにシステムの変更容易性を向上させるためにマイクロサービス化に取り組んだ活動をインタビューしました。 自己紹介 納期表示を高度化する サプライヤ在庫連携機能開発のつらみ AVLのマイクロサービス開発のすすめ方 リリース・監視・その後の展開 おわりに 今回インタビューしたみなさん 自己紹介 山崎 章裕 ECシステムエンジニアリング部門 開発生産性グループ、プラットフォームエンジニアリング部門 CTO-Officeグループ AVLチーム兼務 2019年8月に入社し、主にECサイトの注文・配送周りのプロジェクトにテックリードとして関わる。またECサイ
Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム
AWSが長い間、最高のオープンソースプロジェクトを取り込み、常にそれらのコミュニティに還元することなく再利用し、再ブランド化することで非難されてきたことも周知の事実だ。 AWS gives open source the middle fingerOSSというのは、不思議なソフトウェアだ。世界中で何百万人もの人が一円にもならないのに開発に協力し、コミッタと呼ばれるエンジニアキャリアをOSSに賭ける人々が現れ、多くのユーザがユーザ会を組織し、時には大規模なイベントを開く。MicrosoftやGoogleといった大企業もOSS支援を表明している。GoogleにいたってはandroidとKubernetesという重要なOSSを世に送り出した企業でもあり、その貢献は計り知れない。 そんな中、OSSに対して敵対的、とまでは言わないにしても非常に冷淡な態度を取る企業がある。それがAWSである。本稿では
Software Design 2024年5月号 連載「レガシーシステム攻略のプロセス」第1回 ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計 - ZOZO TECH BLOG
はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 本連載では、ZOZOTOWNリプレイスプロジェクトについて紹介します。2017年に始まったリプレイスプロジェクトにおいて、ZOZO がどのような意図で、どのように取り組んできたのか、読者のみなさんに有益な情報をお伝えしていければと思いますので、ご期待ください。第1回目のテーマは、「ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計」です。 目次 はじめに 目次 ZOZOTOWNリプレイスの背景、目的 背景 目的 柔軟なシステム 開発生産性 技術のモダン化 採用強化 ZOZOTOWNリプレイスの歴史とアーキテクチャの変遷 アーキテクチャの変遷 2004年〜2017年：オンプレミス（リプレイス前） 2017年〜20
はじめに こんにちは、技術本部SRE部カート決済SREブロックの遠藤・金田です。 普段はSREとしてZOZOTOWNのカート決済機能のリプレイスや運用を担当しています。本記事では自作のコマンドラインツールをSlack + AWS Chatbot + AWS Lambdaを使用してChatOps化した事例をご紹介します。「日々の運用業務をコマンドラインツールを実装して効率化したものの今ひとつ広まらない」「非エンジニアにも使えるようにしたい」と考えている方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 ChatOpsとは AWS ChatBotとは 構成 AWS ChatBot チャットツール側の設定 Slack Workflow Lambda 実装のポイント ChatBotのアクセス制御 User Roleの運用方法 ガードレールポリシー コマンドラインツールのLambda関数化
はじめに GuardDuty Malware Protection for Amazon S3は何が嬉しいのか GuardDuty Malware Protection for Amazon S3のコスト GuardDuty Malware Protection for Amazon S3によるスキャンコスト オブジェクトタグの使用コスト S3 API コールのコスト GuardDuty Malware Protection for Amazon S3の運用する上で直面した課題と解決策 AWS Security Hubに統合されていないため、検知に気づきにくい パスを柔軟に指定してスキャンができない マルウェアが検知された場合の隔離機能がない GuardDuty Malware Protection for Amazon S3の制限内でスキャン・隔離・削除する場合 柔軟なパス指定をしてスキ
はてなにおけるEKSの運用と自動化 (2024年版) - Hatena Developer Blog
サービスプラットフォームチームで SRE を担当している id:masayosu です。 先月からですが Hatena Developer Blog にて SRE 連載を始めました。先月の記事は はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog です。 毎月はてなの SRE が交代でブログ記事を書きますのでお楽しみに。 この記事は2024年2月の SRE 連載の記事です。 はてなの EKS 利用について 私が所属するサービスプラットフォームチームでは EKS の運用を続けており、先日 Kubernetes 1.23 から 1.28 へのアップグレードを完了しました。 私のチームは少人数で形成されているのですが、担当しているサービスは大小様々あり EKS クラスター上では数十個のサービスが稼働しています。 少
整備したデータ基盤を、事業部や会社全体で活用に持っていく中で「データカタログ」の必要性が増々注目を集めています。 今回は、データカタログを導入し、データ利活用に挑んでいる6社に、アーキテクチャの工夫ポイントからデータカタログ導入によって得られた効果などを伺いました。 株式会社10X事業内容10Xでは「10xを創る」をミッションとし、小売向けECプラットフォーム「Stailer」の提供を通じて、スーパーやドラッグストア等のオンライン事業立ち上げ・運営支援を行っています。Stailerでは業務構築におけるコンサルティングから、必要な商品マスタやお客様アプリ・スタッフ向けのオペレーションシステム等の提供、配達システムの提供、販売促進の支援など、データを分析しながら一気通貫での支援を行っています。 データカタログ導入の背景以前はデータ分析にデータレイクのテーブルがよく利用されており、カラムのメタデ
こんにちは。技術部プラットフォームグループのshibatchです。プラットフォームエンジニアとして、主にSUZURIとminneをより良くするおしごとをしています。 さて私が主として携わっているSUZURIですが、2014年のサービス開始以来、一貫してHerokuを利用してきました。このたび、10年間使っていたプラットフォームを卒業し、新たにAmazon EKS(Elastic Kubernetes Service)へ移す方針に決めた経緯についてお話しします。EKSに移すという決定にするまでに多角的に検討し、時に悩みながら決定した過程について明らかにしていきます。 なお、現在プラットフォーム移設の真っ最中であり、移設の詳細な内容はこの記事に含めません。移設作業はほぼ完了に向かっており、また別途お話しする予定です。 この記事は以下の3部構成になっています。 Herokuから移行しようと思った
E2Eテスト分析基盤としてReportPortalを導入しました - freee Developers Hub
はじめに 現在のE2Eテスト分析基盤の課題 ReportPortalとは？ 構築方法 ECS or EKS 構成図 インフラコストについて E2Eプロジェクトへの導入方法 Playwrightへの導入 Slack通知への導入 分析ダッシュボードを作成 最後に はじめに こんにちは、SEQチーム (Software Engineering in Quality) の zaki です。 freee QA Advent Calendar 2024 - Adventar 7日目です。 SEQ では、自動テストの運用・改善や基盤開発などを行っています。 現在freeeではJenkinsやGithub ActionsでE2Eテストを実行しています。実行結果のデータをBigQueryに送って、Redashで可視化で不安定なE2Eテストの分析を行なっていました。 しかし、現在のE2Eのテスト分析には一部課
id:cohalzです。この記事は、はてなのSREが毎月交代で書いているSRE連載の2025年1月号の記事です。 2024年にはこのHatena Developer BlogにてSRE連載と言う毎月一回交代でSRE関連のブログ記事を書く企画を開始しました。 今回はその連載記事の紹介と工夫について紹介していきます。 記事一覧 id:hagihala はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 developer.hatenastaff.com readonlyメンテはめちゃくちゃ強力な武器だなと思っているので社内外でももっと広まって欲しいですね。あと0年や10000年も考慮しないといけないというのはまず役に立たない知識でこれも面白かったです。 id:masayosu はてなにおけるEKSの運用と自動化 (2024年版) developer.haten
10年かけて、世界で通用するソフトウェアエンジニアに。自分の得意分野を磨いてキャリアアップ | レバテックラボ（レバテックLAB）
10年かけて、世界で通用するソフトウェアエンジニアに。自分の得意分野を磨いてキャリアアップ 2024年7月22日 OpsBR Software Technology Inc. 代表 岩永 亮介 ソフトウェア業界で15年以上、物理的なデータセンター運用から、世界最大規模の分散システムの運用、多数の業界のお客様のシステム設計支援、フロントエンドからバックエンド、データベース管理者、DevOps やテスト設計・実装、アーキテクチャレビュー、などを経験。特に、運用に関する改善や設計は得意で、OpsBR Software Technology Inc. を立ち上げた。カナダのバンクーバー在住。経歴は、Autify で Staff Software Engineer、Sr. Technical Support Engineer、Amazon で Sr. Systems Development Engi
GKE/EKS（Kubernetes）のコスト可視化を良い感じにしてみた - MonotaRO Tech Blog
はじめに こんにちは！コンテナ基盤グループの楠本です。 今回はマルチテナント運用におけるKubernetesクラスタ内のコスト把握方法についてご紹介します。 見どころは EKSでKubecostを使ってみたがうまくいかなかったこと OpenCostを導入して解消したこと Datadogを使ってマルチクラウドのKubernetesを把握できるようにしたこと の３点です。 はじめに 結果：OpenCost・Datadogを使って出来たもの EKSにKubecostを試験導入してみた スプレッドシートで頑張っていた頃 EC2にかわって出番が回ってきた 過去分は取得できない EBSボリュームの管理 EBSボリュームタイプ レポート出力 インスタンスの割引率 Kubecostに躓いた コストに対するモチベーション OpenCostでリトライ 必要なものはOpenCostとPrometheus Pro
はてなブログや GigaViewer で使われている画像変換プロキシを EC2 から EKS に移行しました - Hatena Developer Blog
こんにちは、サービスプラットフォームチーム アルバイトの id:walnuts1018 です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の 8 月号です。7 月の記事は id:masayoshi さんの はてなで最近実施している SRE 研修の紹介 でした。 今回は、社内共用の画像変換プロキシである、「Scissors」というサービスを EC2 から EKS に移行したお話をしたいと思います。 画像変換プロキシについて 課題点 サービスプラットフォームチームにおける EKS やりたいこと 移行に関する懸念点 Scissors 専用の Node を用意する Pod / Node のオートスケール オートスケールの検証 負荷試験 1 回目 負荷試験 2 回目 リリース まとめ/ふりかえり 画像変換プロキシについて はてなでは「Scissors」という内製の画像変換プロ
t_wadaさんにTROCCO®︎開発の悩みを壁打ちしてもらいました｜株式会社primeNumber
primeNumberのSoftwareEngineerの中根（@gtnao） です。 今回、特別講師として和田卓人さん（t_wadaさん）をお招きして社内勉強会を開催しました！ 勉強会はprimeNumberのオフィスで実施しました。社内には写真のように、広めのイベントスペースがあり、勉強会や輪読会がよく実施されています。 勉強会の様子。20名近くのメンバーが集まりました。勉強会は、ローンチから6年ほど経過したTROCCO®︎が抱えるリアルな悩みを、CTO鈴木（@kekekenta）と私中根が、t_wadaさんに公開壁打ちしてもらうスタイルで行いました。ここから先は、勉強会のアジェンダに沿って内容をご紹介していければと思います。 TROCCO®の前提知識ディスカッションを始める前に、TROCCO®︎の前提知識をt_wadaさんに説明させていただきました。その場で初めて共有する形式だったの
EKSでKubernetes DaemonSetを用いたロギング：Fluent-bitの運用とトラブル事例 - MonotaRO Tech Blog
モノタロウのプラットフォームエンジニアリング部門 コンテナ基盤グループの宋 明起です。 私たちは、アプリケーション開発者からコンテナシステムの認知負荷を取り除き、アプリ開発に専念できるコンテナ基盤の構築と基盤を改善し、開発者はより楽に、より安全にアプリケーションのデプロイと運用できるように支援しています。 背景 基本設計 方針 構成 サンプル モニタリング サンプル 障害 障害1. Memory overflowエラーが発生 障害2. 大量のログが欠損になっている (refresh_interval) 障害3. まだ一部ログが欠損になっている (Prestop) [FAQ] 背景 モノタロウでは以下の記事にあるようにバックエンドのAPIをコンテナ化から始め様々なレイヤーの様々なアプリケーションをEKSの上で運用しています。 EKSコンテナ移行のトラブル事例：ALBの設定とPodのライフサイ
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」を受講しまし
EKSでKarpenterに入学してみた 〜 Fargateを卒業する理由と方法 〜 - MonotaRO Tech Blog
はじめに こんにちは！コンテナ基盤グループの楠本です。 前回の記事EKSコンテナ移行のトラブル事例：FargateにおけるAZ間通信遅延の解消 - MonotaRO Tech Blogを投稿してから半年以上も経ちました。（時が流れるのは早い… 前回はSREグループコンテナ化推進チームとしてでしたが、今回は挨拶の通りコンテナ基盤グループとしての投稿です。 元々ECエンジニアリング部門のSREグループとして活動していましたが、今年初めに組織編成があり、プラットフォームエンジニアリング部門の１グループとして活動しています。 今回は組織とのミスマッチからEKS on FargateからEKS on EC2へ切り替えた話をご紹介します。 見どころは EKS on Fargateとプラットフォームエンジニアリングとの相性 EKS on EC2へ移行する際に検討したこと 移行して得られたこと の３点です
Terraformのversion 1.9が2024年の6月26日にGAになりました。1.9の新機能を見ていきましょう。 変数のvalidationで色々参照できるようになった 変数にはvalidationを実装することができます。例えば以下のようなものです。 variable "aws_account_id" { type = string description = "AWS Account ID" validation { condition = can(regex("^[0-9]{12}$", var.aws_account_id)) error_message = "Invalid AWS accountID." } } これはAWSアカウントIDが格納されるのを想定した変数です。AWSアカウントIDは必ず12桁の数字ですので、そうでない場合はエラーにしています。 上記例では c
コンテナサイズ最小化のためのベースイメージ再考 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
AWS では Amazon ECS、Amazon EKS、AWS Lambda など多くのコンテナランタイムサービスが存在します。そうしたコンテナランタイムを利用する際の最初の一歩として行うのがコンテナイメージの作成です。AWS からも amazonlinux のイメージを提供していますが、デフォルトで 50MB 程度あります。コンテナイメージの起動を極力早く行うために、イメージサイズの削減を行っている方もいらっしゃることでしょう。 コンテナサイズの削減に関しては多くのプラクティスが存在しますが、今回はベースイメージに着目して、それぞれにどういった特徴があるのかを整理していきたいと思います。なお本記事は Dockerfile ベースでイメージをビルドすることを想定した解説になっています。また以下で特に記載がなければイメージサイズは 2025 年 1 月 9 日現在での arm64 用の l
NTTドコモ、全国展開する5Gの無線アクセスネットワークをAWSの「Amazon Elastic Kubernetes Service Anywhere」を用いて展開すると発表
NTTドコモ、全国展開する5Gの無線アクセスネットワークをAWSの「Amazon Elastic Kubernetes Service Anywhere」を用いて展開すると発表 NTTドコモとAWSは、NTTドコモが日本全国で商用展開する5Gの無線アクセスネットワーク（Open RAN）を、AWSの Amazon Elastic Kubernetes Service Anywhere（以下、Amazon EKS Anywhere）を用いて展開すると発表しました。 5Gでは、これまで通信キャリアや通信機器ベンダごとに閉じていた基地局などの無線アクセスネットワーク（Radio Access Network）の仕様を、オープンな仕様にすることで、異なるベンダの機器を組み合わせて構築できるできるようにする「Open RAN」（Open Radio Access Network）が急速に進んでいます
LLMOps基盤のシステムアーキテクチャ目次− 目次 − 対象読者 − TL;DR − 背景：LLMアプリケーション運用の課題 − LLMOps基盤のシステムアーキテクチャ −− 主なコンポーネントと役割 −− Langfuseを採用した理由 − 評価ドリブンなリリースライフサイクルの全体像 − オンライン評価プロセス −− 1. ログ・トレースデータの保存 −− 2. 評価とアノテーション − オフライン評価プロセス −− プロンプト実験 −− LLMアプリケーション統合実験 − 今後の展望 − 終わりに − 参考文献 こんにちは！Eureka AI Teamで、Pairs（ペアーズ）のMLOps Engineerをしているnariです。 こちらは、Eureka（Pairs） Advent Calendar 2024 の10日目の記事です。 本日は、私たちが構築した「LLMOps基盤」と
障害への不安をぶっ壊す！カオスエンジニアリングを運用しシステムとチームの耐障害性を高める - ZOZO TECH BLOG
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの山本です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。 我々のチームは、複数サービスを運用する中で障害対応の経験不足や知見共有の難しさといった課題に直面していました。そこで、半年ほど前にカオスエンジニアリングの導入を開始しました。 本記事では、カオスエンジニアリングを一過性のものではなくチームの文化として根付かせ、継続的な改善サイクルを生み出すための導入から運用まで、我々のチームでの実践から得られた具体的な方法をお伝えします。 これからカオスエンジニアリングを始めようとしている方はもちろん、すでに導入しているものの効果的な運用に悩んでいる方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 カオスエンジニアリング導入の流れ 1. 目標とKPIの設定 1.1 目標
こんにちは、クラウド事業部の中根です。 未経験からKubernetesに入門して約１か月が経ったので、振り返りたいと思います！ 実務に入る前の予習なので、実務を通した実践的な学習はしていない点はご了承ください。 学習の動機 入門前のレベル感 学習プロセス 入門0～7時間 入門7～32時間 入門32～60時間目 入門60～71時間目 入門71～132時間目 +α できるようになったこと 次のステップ これから入門する方へ おわりに お知らせ 学習の動機 私は中途入社で、案件は決まったのですが、参画まで1か月半ほど待機期間となりました。 クラウドネイティブな案件ということで、この期間を活かしてKubernetesのキャッチアップをすることになりました。 入門前のレベル感 IT業界経験が3年と1か月です。 以下、関係する領域の詳細です。 Kubernetes ほぼ未経験。 OpenShiftをち
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クレディセゾンでDXを進めてきた5年間を振り返る｜小野 和俊
AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠
NATゲートウェイの通信内容を調査して対策し、コストを約60％削減した話 - ZOZO TECH BLOG
【書評】マルチテナントSaaSアーキテクチャの構築 | DevelopersIO
個人開発でもADR （アーキテクチャデシジョンレコード）を書くことの利点 - laiso
身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools
手に職がない35歳エンジニアが如何にしたら転職できるか考えてほしい
モバイルゲームのインフラアーキテクチャ特集 - 技術選定のポイントと今後の展望 - Findy Tools
N予備校のインフラを Amazon EKS に移行した話 - ドワンゴ教育サービス開発者ブログ
クラウドエンジニアになるために必要な技術 5選（ハンズオン付き） - Qiita
ソフトウェアと愛 - あるいはOSSとAWSの確執｜ミック
ChatOpsによる運用作業の自動化 - ZOZO TECH BLOG
GuardDuty の機能を使って S3 のウィルスチェックをしよう！ - NRIネットコムBlog
データカタログ特集 データ利活用に向けたアーキテクチャ6選 - Findy Tools
なぜSUZURIはHerokuから「EKS」へ移設する決定をしたのか - Pepabo Tech Portal
2024年に始めたSRE連載について - Hatena Developer Blog
Terraform 1.9 の新機能紹介 | DevelopersIO
ペアーズにおける評価ドリブンなリリースサイクル：Langfuseをフル活用したLLMOps基盤
【Kubernetes】未経験から1か月経ったので振り返る - APC 技術ブログ