スタートアップのエンジニアの交流や知見の共有を目的とする、AWS Startup Community 主催の技術系オンラインイベント「AWS Startup Tech Meetup Online #5」。ここでユニファ株式会社の赤沼氏が登壇。「午睡チェック」の概要とアーキテクチャについて紹介します。 自己紹介 赤沼寛明氏（以下、赤沼）：よろしくお願いしますみなさまこんばんは。ユニファでCTOをしています、赤沼と言います。 今日はAWS Startup Tech Meetupということで、弊社ではプロダクトをすべてAWS上で構築しているんですが、その中でも「ルクミー午睡チェック」というサービスがありまして。その中でDynamoDBやSQSというのを活用してるところがあるので、主にそのあたりにフォーカスして紹介したいと思っております。 まず簡単に自己紹介します。私は6年前、2015年に1人目の
AWS Summit Tokyo 2019 I3-04「ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker運用の知見」レポート - ForgeVision Engineer Blog
こんにちは、クラウドインテグレーション事業部 山口です。AWS Summitも３日目となり寂しい感じですが、予定していたスピーカーセッションなども終わり、やっとセッションを聞けたのでレポートを書きます。 ロマサガ大好きで初代は３拠点制覇実績もあり、更に大好物のコンテナがテーマとなれば参加しない理由はありません、セッション会場へダッシュです。AWS Summitの事例セッションは動画公開されないことも多いので、テクニカルセッションよりも事例を優先的に聞く立ち回りも理由の１つですね。 ＜注意＞このセッションは録画＆配信されるようですので、詳細はAWS公式より公開される動画を参照ください。メモの共有ということでブログにします。撮影禁止なのでテキスト中心の内容となります。 第１章 ロマサガRS アーキテクチャ Elixirをベースに開発 強力な並列処理が魅力 ECSベースで稼働、インフラはClou
Kubernetesの負荷試験で絶対に担保したい13のチェックリスト - Enjoy Architecting
概要 ここ最近、Kubernetesクラスタを本番運用するにあたって負荷試験を行ってきました。 Kubernetesクラスタに乗せるアプリケーションの負荷試験は、通常の負荷試験でよく用いられる観点に加えて、クラスタ特有の観点も確認していく必要があります。 適切にクラスタやPodが設定されていない場合、意図しないダウンタイムが発生したり、想定する性能を出すことができません。 そこで私が設計した観点を、汎用的に様々なPJでも応用できるよう整理しました。 一定の負荷、スパイク的な負荷をかけつつ、主に下記の観点を重点的に記載します。 Podの性能 Podのスケーラビリティ クラスタのスケーラビリティ システムとしての可用性 本記事ではこれらの観点のチェックリスト的に使えるものとしてまとめてみます。 確認観点 攻撃ツール 1: ボトルネックになりえないこと Podレベル 2: 想定レイテンシでレスポ
AWSエンジニアから見たGCP(データ分析編)
こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。前回の記事「AWS SAPを取得したら視野が広がった話」を読んでいただいた方々、ありがとうございます。今回のテーマは「AWSエンジニアから見たGCP」第2弾として、代表的なGCPのコンピューティング系サービスについてAWSと比較し感じた点についてお話いたします。 (第1弾の記事はこちら↓)IaaSCompute EngineAWSではEC2に相当するサービス。各種インスタンスタイプや提供OSイメージ、インスタンス向けのストレージ機能、オートスケール機能など、インスタンスのアーキテ... DWH BigQuery BigQueryはフルマネージドなサーバレスDWHサービスで、Googleが開発した大規模データ向けの分散システムであるDremelを基にしておりSQLクエリを使用して大規模データの分析を行うことができる。さ
はじめに そもそもcommmune って何？ サービスの紹介 特性について 旧アーキテクチャとその問題点 問題１：増減するトラフィックに対してコスト最適なマシンスペックを設定するのが運用上難しかった 問題２：トラフィックのスパイクでサービスが過度に不安定になっていた 問題３：動作環境としてのVMの管理が煩雑になってしまっていた 打ち手としての新アーキテクチャ 新アーキテクチャ サービス選定の内訳 成果 新たな課題 最後に はじめに こんにちは。 前原夏樹と申します。 コミューン株式会社のSREチームでアクティングマネージャーをしています。 今日は当社のプロダクトであるcommmuneのアーキテクチャについてざっくり紹介していきたいと思います。 今回公開に至った動機としては知見の共有が最も大きいです。 運用負荷が比較的低いマルチテナントSaaSのアーキテクチャの具体的な一例として、どのような
ECS×Fargate ターゲット追跡ServiceAutoScallingを使ったスパイク対策と費用削減 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、ターゲット追跡ServiceAutoScallingを使い、ECS×fargateで運用しているサービスのスパイク対策と費用削減に取り組んだのでその内容をまとめています。 内容はざっくり下記4項目について書いています。 抱えていた課題 キャパシティプランニングに対する考え方 ECS ターゲット追跡ServiceAutoScallingとは何か? どんな結果になったか? 抱えていた課題 コネヒトでのWebのアーキテクチャはほとんどがECS×Fargateの基盤で動かしています。 ECSのバックエンドをEC2からFargateに移行したタイミングで、大きく下記2点のメリットは享受していました。 EC2を意識しないことでの運用コスト削減 オートスケールの容易さ ですが、サービス運用にあたりまだ下記のような課題がありました。 ①
アーキテクチャレビューはじめました
FiNCの篠塚(@shinofumijp)です。4月からCTOを拝任しました。 本記事では1月から行ってきた「アーキテクチャレビュー」という取り組みについて紹介します。 FiNCではマイクロサービスを6年前から採用しており、順調にサービスも成長したおかげで、現在では稼働しているマイクロサービス数は50を超えるほどになりました。 マイクロサービスの採用により、限られた範囲での開発においては速度を落とさずスケールすることが可能という恩恵を得られましたが、一方でサービス数の増加は安定性、メンテナンス性をはじめとした様々な問題も生みました。その1つにアーキテクチャ全容の理解が困難になるという問題があります。例えば「ユーザが食事を投稿した際に食事アドバイスのプッシュ通知を送る」という機能1つをとっても、アドバイス管理サービスが食事投稿のイベントを検知するためにイベントを購読し、同サービスがアカウント
LIFULLを支えるKubernetesエコシステムまとめ 2020年版 - LIFULL Creators Blog
技術開発部の相原です。 以前にブログで書きましたが、LIFULLでは主要サービスのほぼ全てがKubernetesで稼働しています。 www.lifull.blog Kubernetesをアプリケーション実行基盤として本番運用するためにはデプロイやモニタリング・ログ、セキュリティなど考えることが多くどこから手を付ければよいか困ることがあるでしょう。 そこで今回は既に数年の運用実績のあるLIFULLのアプリケーション実行基盤で利用しているKubernetesエコシステムについて紹介します。 全て書くと数が膨大になるので今回はクラスタ周りを中心に、必要とするソフトウェアの数が多いモニタリング・ログまでとします。(それでも大作になりそうですが...) kubernetes/kops projectcalico/calico coredns/coredns node-local-dns kubern
Cloud Runで新規サービスを構築・運用するためにSREとして取り組んだこと - ZOZO TECH BLOG
はじめに こんにちは。メディアプラットフォーム本部 WEAR部 WEAR-SREの笹沢（@sasamuku）です。 ZOZOが新しく展開する「FAANS」というショップスタッフ向けアプリをクローズドβ版としてテスト運用しています。本アプリは、WEARと連携したコーディネート投稿や、その成果を可視化する機能などをショップスタッフの皆さんに提供するtoBのソリューションです。現在、正式リリースに向け開発を進めています。 そして、FAANSのAPIはCloud Runと呼ばれるサーバレスなコンテナ実行基盤で稼働しています。本記事では、FAANSの実行基盤としてCloud Runを選定した理由や、構築・運用するためにSREとして取り組んだことをご紹介します。 Cloud Runを選んだ理由 まず、クラウドサービスはGCPを選択しています。FAANSでは開発速度の向上と運用負荷の軽減のため、認証やメ
はじめに こんにちは。計測プラットフォーム開発本部SREブロックの纐纈です。今年の4月に入社し、ZOZOMATやZOZOGLASSの運用改善に取り組んでいます。また、今年の夏US向けにZOZOFITをリリースしましたが、そちらの機能追加にも今後関わっていく予定です。 計測システムでは最近Argo Rolloutsを導入してカナリアリリース、自動ロールバックを実現しました。本記事では、その具体的な導入方法と効果についてお伝えします。 目次 はじめに 目次 Argo Rollouts導入前のリリースの問題 カナリアリリースの導入 導入後の効果 ツールの選定 Argo Rolloutsについて DeploymentからRolloutへの移行 1. 既存のDeploymentを参照するRolloutリソースを作成して、Podを立ち上げる 2. HPAの対象をDeploymentからRolloutに
Kubernetesを分散ストレージのプラットフォームにする「Rook」、成熟したソフトウェアに到達したとしてCNCFがインキュベーションからの卒業を発表
Kubernetesを分散ストレージのプラットフォームにする「Rook」、成熟したソフトウェアに到達したとしてCNCFがインキュベーションからの卒業を発表 Kubernetesなどのソフトウェア開発をホストしている団体「Cloud Native Computing Foundation」（CNCF）は、Kubernetesを分散ストレージのプラットフォームにする「Rook」が、十分に成熟したソフトウェアに到達したとして、インキュベーション段階からの卒業を発表しました。 [NEWS] @CloudNativeFdn Announces @rook_io Graduation https://t.co/47DmD0LK2x pic.twitter.com/zsk7YQiQ57 — CNCF (@CloudNativeFdn) October 7, 2020 RookはKubernetesにさま
「Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です。 →【かんたん30秒】無料登録で転職相談する 開発スピードを向上させるFirebase ーー：早速ですが、まずは村本様とFirebaseの関わりについてお伺いしてよろしいでしょうか。 村本：もともと、いくつかの会社でアプリエンジニアとして働いており、現在は独立して複数の企業の技術顧問を勤めています。特にFirebaseのコンサルティングに力を入れていますね。 日本最大のコミュニティグループである Firebase Japan User Groupを立ち上げ、オーガナイザーとしても活動しています。 ーー：既存のプラットフォームで開発するのと比べて、Fi
任天堂株式会社の導入事例：ビッグタイトル『Super Mario Run』のバックエンドを支えた Google App Engine | Google Cloud 公式ブログ
昨年末にリリースされ、任天堂初のスマートフォン向け本格ゲームアプリとして注目された『Super Mario Run（スーパーマリオ ラン）』。その背後では、文字通りケタ違いのアクセスをさばく強力なバックエンドが稼働していました。任天堂、DeNA そして Google が一丸となって取り組んだ、その開発ストーリーをお届けします。 ■利用している Google Cloud Platform サービス Google App Engine Google BigQuery Google Cloud Dataflow Google Cloud Datastore Google Cloud Pub/Sub Google Cloud Storage Google Stackdriver (Logging, Monitoring, Trace, etc) など ■任天堂株式会社 1980 年代に『ファミリー
PostgreSQL + Rails へ PgBouncer を導入してDBメモリ使用量を大幅に改善した話 - Hello Tech
uiu です。ハローでは普段バックエンド開発をメインに担当していますが、創業以来片手間でインフラも担当しています。 ハローでは、少数精鋭のメンバーの意識をプロダクト開発に集中するため、インフラ面では Cloud Run などマネージドなサービスを最大限に活用しています。 今回は、久しぶりにインフラに意識の一部を捧げ、いくつかの眠れない夜を過ごす機会があったので、インフラ面の話について紹介しようと思います。 スタートアップと PostgreSQL AutoReserve はサービス立ち上げ以来、DB は PostgreSQL、APPサーバーは Ruby on Rails のバックエンド構成で運用してきています。 特に PostgreSQL は立ち上げ以来安心して使い続けられている技術要素です。サービス運用から(ある規模までの)分析まで PostgreSQL だけで回せる点は、少人数でプロダク
GitHub ActionsのワークフローをオートスケールするSelf-hosted runnerに移行した話 - Mobile Factory Tech Blog
こんにちはエンジニアのEadaedaです。 皆さんのチームではGitHub Actionsを使っていますか？ブロックチェーンチームではテストやリンター、デプロイといったワークフローをGitHub Actionsで行っています。 今まで、デプロイ以外のワークフローはGitHub-hosted runnerで実行、デプロイはSelf-hosted runnerで実行していましたが、運用していくうちに特定の環境内にあるサーバーで実行されるように仕組みを見直す必要がでてきました。このため全てのワークフローをSelf-hosted runnerに移行する対応を行いました。この記事では移行の際に見つけた便利なものや困ったことを紹介します。 Self-hosted runner GitHub Actionsでは、基本的にGitHubが用意したVMでワークフローが実行されます。このVMをGitHub-ho
はじめに はじめまして、とある高校3年生です。 皆さん、不要不急の外出は自粛していますか？ 新型コロナウィルスの感染拡大が止まらず、僕の住んでいる兵庫県でも多くの感染者が出ています。 3月初旬にシリコンバレーに行ったのですが、帰国後すぐに感染爆発が起きて、アメリカは今大変な状況になっていて、その変化を見たからか個人的に新型コロナに対してはすごく危機感を持っています。 学校もゴールデンウィーク明けまで休みになってしまい、外出もできないため、家でボーッと積読だった本を片付けたり、Twitterを眺めていたり、YouTubeでどうぶつの森の動画を見て癒やされていたり、、するような生活を送っています。 それでいいのか？ 飲食業界やイベント業界では大打撃を受けて、テイクアウトやオンラインイベントを行うなど一生懸命に取り組んでいる人がたくさんいるというのに、僕はただ不安を抱えて家にこもってるだけ。 高
こんにちは、インフラ部の id:sue445 です。 今回はRendertronをGKEとCloud Runの両方で構築した話をしたいと思います。 tl;dr; 前置き 今までのRendertronの問題点 GKE版Rendertronについて GKEの採用理由について GKE版Rendertronの構成 全体 GKE内部 pod内部 Kubernetesの設定と解説 rendertron-deployment.yaml rendertron-hpa.yaml rendertron-ingress.yaml rendertron-service.yaml Tips nodeのストレージサイズをケチり過ぎたらpodが起動できなくなった N1マシンタイプのnodeとN2マシンタイプのnodeを比較した結果、N2マシンタイプが安くなった Cloud Run版Rendertronについて Clou
[DevSecOps] コンテナ時代のアンチウィルス対策はどうすればいいのか調べてみた｜Anno Takahiro
エンタープライズ企業が新しいクラウドサービスを導入する時には、自社のセキュリティ基準を満たせていることを確認するのが通例である。「セキュリティチェックシート」と呼ばれるエクセルシートを利用して一点一点チェックしていくことが多い。（この質問票で聞かれる内容が個社ごとにばらばらで、システム導入時に双方の負担になってしまっているのを標準化してなんとかできないかと思うことはあるが、この記事ではそこには触れない。） よくあるのが、「アンチウィルスソフトウェアをサーバーにインストールしていること」というチェック項目だ。明快な質問のように見えるが具体で実現するためには色々考えなければいけないことがある。標準的なサーバー構成、つまり、ハードウェアがあって、その中でOSが稼働していて、その上でアプリケーションが動いているというシンプルな構成であれば良いのだが、クラウドインフラを使い倒すようになった今ではマイ
![[DevSecOps] コンテナ時代のアンチウィルス対策はどうすればいいのか調べてみた｜Anno Takahiro](https://cdn-ak-scissors.b.st-hatena.com/image/square/d40f582c13ec7b50a24702f677080474932e9b61/height=288;version=1;width=512/https%3A%2F%2Fassets.st-note.com%2Fproduction%2Fuploads%2Fimages%2F24412229%2Frectangle_large_type_2_8c36b95904fe1cfb50326f80f7e5b1fb.jpeg%3Ffit%3Dbounds%26quality%3D85%26width%3D1280)
G-gen の杉村です。BigQuery のオンデマンドクエリの利用量にフタをする、つまりスキャンデータ量に上限を設けて突発課金を防止する工夫について紹介します。 はじめに 割り当て (Quota) の設定 Query usage per day 設定手順 割り当て画面へ遷移 対象の割り当てをフィルタ 編集ボタンをクリック 割り当てを設定 新しい割り当ての確認 動作確認 クエリのサイズ上限設定 クエリ単位での上限設定 設定手順 (コンソール) クエリ設定を開く 詳細オプションの設定 動作確認 設定手順 (bq コマンドライン) はじめに BigQuery の課金体系にはオンデマンドと Editions の2つから選択できます。前者はスキャンしたデータ量に応じた従量課金です。後者は確保するコンピュートリソースの量に応じた課金で、オートスケールの幅 (上限と下限) を設定できます。 Editi
DeNAがデータプラットフォームで直面した課題と克服の取り組み
はじめにこんにちは。この記事はDeNAの小口（Rikiya Oguchi）と長谷川（Ryoji Hasegawa）がお届けします。 小口はゲーム事業部の分析部データエンジニアリンググループの所属で、長谷川は全社共通部門である分析推進部の所属です。ゲーム事業部と全社部門で所属は違いますが、近しいミッションのもと、普段から密に連携して仕事をしています。 DeNAでは現在、データプラットフォームの刷新を進めています。この記事では、そのプロジェクトについて、以下の流れでご紹介します。 現行データプラットフォームの背景と概要データプラットフォーム構築後の環境変化現行データプラットフォームが抱える課題現行組織が抱える課題データプラットフォームの刷新刷新後のシステム構成組織体制の刷新我々と同じようにデータプラットフォームの構築・運用に携わっている方々や、データプラットフォームを利用されている方々、特に、
EKSコンテナ移行のトラブル事例：推測するな計測せよ -CoreDNS暴走編- - MonotaRO Tech Blog
こんにちは、モノタロウの SRE グループ・コンテナ化推進チームの田中です。 現在、私たちはシステムモダナイゼーションのプロジェクトの一環として、200以上のエンドポイントを持つモノリスのバックエンド API を EC2 上から Kubernetes マネージドサービスの EKS（Elastic Kubernetes Service）に移行しています。ノードは Fargate を使用し、監視には Datadog と Sentry を導入しています。 今回、EC2 に流れているリクエストを全て EKS に振り分けを行おうとしておりました。その際に外部（DB、 サービス）への疎通ができないといった内容の Sentry のエラーが大量に発生し、切り戻しをせざるを得ない状況に陥ったのです。エラー内容を詳しくみたところ名前解決に関するものであり、今回私たちは CoreDNS の設定を行うことで解決し
OSSにコントリビュートしてログ収集基盤におけるCloud Pub/Subのリージョン間通信費用を削減した話 - ZOZO TECH BLOG
こんにちはSRE部の川津です。ZOZOTOWNにおけるログ収集基盤の開発を進めています。開発を進めていく中でCloud Pub/Subのリージョン間費用を削減できる部分が見つかりました。 今回、OSSであるfluent-plugin-gcloud-pubsub-customにコントリビュートした結果、Cloud Pub/Subのリージョン間費用を削減できました。その事例を、ログ収集基盤開発の経緯と実装要件を踏まえて紹介します。 目次 目次 ログ収集基盤の紹介 開発経緯 フロントエンドのログしか取得できない BigQuery ExportはSLAを担保されていない リアルタイムにログを保存できない 実装要件 ログ送信側の環境に依存しない共通の仕組みで実装する 転送されるログの量に応じてオートスケールする構成にする 送られてくるログをロストしない リアルタイムにログが保存される インフラ構成
こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。 前回の記事「AWSエンジニアから見たGCPサービス(コンピューティング編)」を読んでいただいた方々、ありがとうございます。 こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。前回の記事「AWS SAPを取得したら視野が広がった話」を読んでいただいた方々、ありがとうございます。今回のテーマは「AWSエンジニアから見たGCP」第2弾として、代表的なGCPのコンピューティング系サービスについてAWSと比較し感じた点についてお話いたします。 (第1弾の記事はこちら↓)IaaSCompute EngineAWSではEC2に相当するサービス。各種インスタンスタイプや提供OSイメージ、インスタンス向けのストレージ機能、オートスケール機能など、インスタンスのアーキテ... 今回は「GCPサービスで構築された
Masanori Kusunoki / 楠 正憲 on Twitter: "#クラウド蓮舫 がどうして馬鹿にされてるのか分からないけど、オンプレのサーバー増設は時間がかかるけどクラウドなら時間をかけずに増設できるといいたかったのでは？会計法が硬直的で従量課金への対応が困難とか、JPKI関係がオートスケールできない設計であることは枝葉末節で"
#クラウド蓮舫 がどうして馬鹿にされてるのか分からないけど、オンプレのサーバー増設は時間がかかるけどクラウドなら時間をかけずに増設できるといいたかったのでは？会計法が硬直的で従量課金への対応が困難とか、JPKI関係がオートスケールできない設計であることは枝葉末節で
カナリアリリースを自動化！Flaggerでプログレッシブデリバリーを実現した話 - ZOZO TECH BLOG
はじめに こんにちは。SRE部ECプラットフォーム基盤SREブロックの大澤と立花です。 本記事ではマイクロサービスのカナリアリリースに関して私達が抱えていた課題と、それをFlaggerによるプログレッシブデリバリー導入でどのように改善したのかを紹介します。 ZOZOTOWNのマイクロサービス基盤におけるカナリアリリース手段の変遷については以下のテックブログで紹介しておりますので気になった方はご参照ください。現在はIstio VirtualServiceの加重ルーティングを用いたカナリアリリースに一本化しております。 techblog.zozo.com techblog.zozo.com 目次 はじめに 目次 カナリアリリースの運用課題 解決手段としてのプログレッシブデリバリー Flaggerとは？ Flaggerによるプログレッシブデリバリーの進み方 Flagger導入時の検討ポイント (
完全招待制のオンラインカンファレンス「PIXIV MEETUP 2023」。「創作活動を、もっと楽しくする。」というミッションを遂行するために、メンバーが普段行っている業務について、自らの言葉で語り、その想いと技術を共有する場です。sue445氏は、 ピクシブ社における、パブリッククラウド活用の取り組みについて発表しました。全2回。前半は、sue445氏が入社後に取り組んだ、GitLab CIのオートスケール化やTerraform導入などについて。 登壇者の自己紹介 sue445氏：「pixiv Cloud Journey」というタイトルで発表させてもらいます。 こちらの発表資料ですが、先ほど「X」にハッシュタグ付きで流しているので、後から見返したいという方は、そちらのURLをご覧ください。 自己紹介させてもらいます。末吉剛といいます。SNSでは「sue445（すえよんよんご）」というID
こんにちは。前回書いた突撃！隣のキーボード M3 2019という記事が、HHKBの公式Twitterアカウントにツイートされ、舞い上がっているエムスリーエンジニアリングGの河合 (@vaaaaanquish) です。 今回はエムスリー AIチームが開発、運用している機械学習プロジェクト向けのPythonライブラリである「gokart」の説明と、その周辺ライブラリとなる「cookiecutter-gokart」「thunderbolt」「redshells」について紹介したいと思います。よろしくお願いします。 はじめに Pipeline化のメリット・デメリット Pipeline化のメリット Pipeline化のデメリット gokart 共通化のための出力ファイル形式の制約と拡張 強力かつ簡易な再現性のためのデータ保持 クラウドサービスやSlack通知のサポート gokartのメリット、デメリ
はじめに これは、ZOZOテクノロジーズ #4 Advent Calendar 2019 13日目のエントリーです。 前回の前編記事に引き続き、Airbnbのエンジニアたちが経験したクラスターでのやらかしをあれこれご紹介します。 6. Where's my Custom Resource?（ワイのカスタムリソースはどこに？） AirbnbではKubernetesのCustom Resourceをよく使用しています。 特に、Kubernetesクラスターの外部にあるが、ストレージ、ダッシュボード、アラート、IAMロールなどのAWSリソースなどのサービスに関連付けられているリソースを追跡するために使っています。 こうしたCustom Resourceを使う上で大変なのが、「そのリソースがいつ利用可能になったか」や、「そのリソースに関する変更がいつ反映されたか」を検知することです。 最初のうちは
こんにちは！FIXER R&D Division担当、フェローの千賀です。 今日は、先日8月23日に発生したAWSでの大規模障害を受けて、クラウドを使ってシステムやサービスを構築、提供する際の考え方や留意事項等をお伝えし、止まらないサービスを作るにはどうしたらいいかをアーキテクチャの観点から解説したいと思います。 AWSでの障害の内容と原因 まず簡単に、AWSで2019年8月23日に発生した障害の原因や内容を簡単に解説します。既に当ブログでも取り上げ、報道などもされておりますのでご存知の方も多いかもしれませんが、同日正午過ぎごろから22時過ぎまでの間、AWS東京リージョンにて、EC2やRDSへの接続障害など発生しました。原因は冷房をコントロールする制御システムを中心とする多重障害であり、サーバの温度が上がりすぎたことによる過熱である、と報告されています。 これにより約10時間に渡って、AW
読まれる技術ブログを書くヒント - 企業技術ブログ
忙しい業務の合間をぬって書く技術ブログ、せっかくなら多くの人に読まれたいですよね。 エンジニア向けメディアなど、企業のコンテンツマーケティング支援やHatena Developer Blogの編集サポートなども担当しているはてなの編集者に、読まれる技術ブログを書くヒントや、はてなで実践している工夫について聞いてみました。ブログを書く際に、よろしければ参考にしてみてください。 記事タイトルにこだわりましょう人は記事タイトルを見て、中身を読むか判断します。つまり、タイトルの書き方ひとつで読まれやすくもなるし、逆に損をすることもあるのです。読まれるブログを目指すとき、まず記事タイトルに注力することをおすすめします。 見出しを読み手への道標に活用しましょう「いま何の話をしているのか」読み手が迷わない道標として、見出しを活用しましょう。 目次を見て、各セクションにどんなことが書いてあるのかイメージで
Knative Servingを用いて多数の開発環境APIを低コストで構築する - ZOZO TECH BLOG
はじめに こんにちは、技術本部ML・データ部MLOpsブロックの鹿山（@Ash_Kayamin）です。先日、20個の開発環境APIを用意し、各APIをリクエストに応じて動的に起動できる仕組みをKnative Servingを用いて構築しました。 この記事ではKnative Servingを利用した背景と、利用方法、はまりどころ、利用によって得られたコスト削減効果についてご紹介します。なお、今回はKubernetesクラスタのバージョンとの互換性の都合でKnativev1.3.1を利用しました。2022/9現在の最新バージョンはv1.7.1になりますのでご注意ください。 目次 はじめに 目次 課題：20個の異なる開発環境APIを低コストで提供したい 解決策：Knative Servingを用いて、リクエストに応じて動的にAPIサーバーを起動する仕組みを導入する Google Cloud上でA
KubernetesのPodを事前にスケールアウトする仕組みをCronJobで実装し、ジョブの処理遅延を低減した話 - ANDPAD Tech Blog
1. はじめに こんにちは、SWEのあかりです。 今回は、SREの角井さん（@cass7ius）と一緒に、Kubernetes(以降、K8sと表記)のPodを事前にスケールアウトする仕組みをK8sのCronJobで構築したので、その実装背景・技術選定・実装方法について実例を紹介します。 この記事を読んで得られるものは以下の3点です。 Podを事前にスケールアウトさせて、ジョブの遅延を低減した実例 技術選定時に行った定性分析の実例 Podからkubectlコマンドを実行する実装例 2. 前提の説明 掲題の実装対象は施工管理サービスであり、これは社内で最も古くから稼働しているモノリシックなRailsアプリケーションです。施工管理サービスのおおよそのインフラ・技術構成は下図の通りになっています。 施工管理サービスのインフラ構成図 上図の通り、施工管理サービスはEKSクラスター上で稼働しており、お
本記事は、Gunosy Advent Calendar 2020 7日目の記事です。 前回は、しゅんけー君の「その実験、再現できますか？pyenvとpoetryによる “そんなに頑張らない” 再現可能な実験環境構築」でした data.gunosy.io はじめに 前提条件 目指すクラスター像 使用するサービス・ツール類 K8Sを使う上での心構え 環境設計編 環境設計 リポジトリ クラスター構築・前編（EKSクラスター） クラスター構築・中編（ASG） ASG or Fargate ASG spotインスタンス はじめに Gunosyの大関と申します。いくつかのEKSクラスターとクラスター上で稼働するサービスの開発運用を、基盤レイヤーを中心に担当しています。 昨年のadvent calendarでは、こんな記事を書いていました。 tech.gunosy.io さて、今年一年で社内の様々なサー
人間によるKubernetesリソース最適化の”諦め”とそこに見るリクガメの可能性 | メルカリエンジニアリング
Platformチームでエンジニアをしているsanposhihoです。メルカリのPlatformチームでオートスケーリング周りの課題の解決を担当しており、Kubernetes UpstreamでもSchedulingやAutoscaling周りの開発に参加しています。 メルカリでは全社的にFinOpsに取り組んでおり、Kubernetesリソースは最適化の余地があるエリアです。 メルカリではPlatformチームとサービスの開発チームで明確に責務が分かれています。Platformではサービス構築に必要な基礎的なインフラストラクチャを管理し、それらを簡単に扱うための抽象化された設定やツールなどの提供を行っています。サービスの開発チームは、それらを通してサービスごとの要件に応じたインフラストラクチャの構築を行います。 サービスやチームの数も多く、そのような状況での全社的なKubernetesリ
EC2で運用しているWordPressサーバーをECS/Fargateに移行しました | ランサーズ（Lancers）エンジニアブログ
SREチームの安達(@adachin0817)です。今回WordPressサーバーであるEC2からECS/Fargateに移行しましたが、紆余曲折を得て、苦労したところ、技術的な部分、最終的には複数のリポジトリを一つにまとめたことなどを紹介したいと思います。まずはプロジェクトとサーバーの構成から説明していきましょう。 ランサーズのWordPressとECS時代のサーバー構成 https://engineer.blog.lancers.jp https://info.lancers.jp https://l-ap.jp https://connect.lohai.jp https://lohai.jp https://tips.lancers.jp https://www.lancers.co.jp https://www.lancers.jp/assistant/cases https:/
2019年5月23日、DMM.comとZOZOテクノロジーズによる合同勉強会「DMM x ZOZOを支える基盤技術」が開催されました。数多くのサービスを展開している2つの巨大プラットフォームは、どのようなインフラ基盤・運用によって支えられているのか？ 2社で活躍するエンジニアたちが、その舞台裏を明かします。プレゼンテーション「ZOZOSUITによる計測システムの裏側について」に登壇したのは、株式会社ZOZOテクノロジーズ の指原卓也氏。講演資料はこちら ZOZOSUITを用いた計測システムの裏側 指原卓也氏（以下、指原）：こんばんは。僕からは「ZOZOSUIT計測システムの裏側について」をお話させていただきます。 最初に簡単な自己紹介です。 ZOZOテクノロジーズでSREチームのリーダーやっている指原と申します。2011年に入社し、ファッション通販サイト「ZOZOTOWN」の開発に2年ほど
docker-compose ライセンスは、Apache License 2.0 1.29.2 (2021/05/10) docker-composeをインストールなしで使う Docker Compose UI ライセンスは、MIT License v1.13.0 (2018/05/21) docker-composeのWeb UI Composeファイルのフォーマットバージョンは、3.6まで対応 Dockerイメージ Docker Compose UIのリポジトリをフォークしてComposeファイルのフォーマットバージョン3.7対応版(Python 3.8、Flask 1.1.2、docker-compose 1.25.5、gitpython 2.1.15にバージョンアップ)を以下のリポジトリに置きました。 まだ動作確認が十分にできていませんが、Logs、Restart、yamlのedi
# はじめに GitHub Changelog を元に、GitHub Actions がどのように更新されていったかを簡単にまとめました。 あまり深いところまでは書いてないので、気になった変更があったら各自調べてください（もっと色々書きたかったけど時間なかった）。 わりと雑に作ったので漏れや間違いがあったらコメントとか下さい。 2021/12/01 までの情報をもとにこの記事は書かれています。 この記事は GitHub Actions Advent Calendar 2021 の 1 日目の記事です 🎅🎂 目次 # はじめに # 歴史 ## 発表 〜 正式リリース（2018/10 〜 2019/11） ## 2020 ### 1Q + α ### 2Q ### 3Q ### 4Q ## 2021 ### 1Q ### 2Q ### 3Q ### 4Q ## 2022 ### 1Q #
qiita.com こんにちは、はじめまして。虎の穴ラボのはっとりです。 虎の穴ラボ Advent Calendar 2020 - Qiita - Qiita 7日目の記事になります。 6日目はT.MさんのSaaSに関する記事です。 toranoana-lab.hatenablog.com 8日目は、礒部さんの画像判別ボットに関する記事です。 toranoana-lab.hatenablog.com 新規サービスに携わることになり、その際AWS Fargateを使った環境構築を担当したので構築方法を共有します。 この記事で話さないこと アプリケーション側の作り こちらはまた別の機会に紹介したいと思います。 構成管理ツールなどによる環境構築 特定のツールによる環境構築ではなくGUIでもできる手順にしています。 全体構成 今回紹介する範囲での全体構成は下記の通りです。 アプリケーションはfro
Knativeはサーバーレスのビルディングブロックであるという文脈でで説明されることが多く、本来メリットを受けることができるはずのKubernetes上のアプリケーションやマイクロサービスの開発者、運用・管理者などに便利な機能が伝わってない説があったりなかったりするようです。 サーバーレスや抽象化という「言葉から想像される何か」は人により異なり、共通の認識が築かれないまま議論がかわされ、具体的に検証されないのはとてももったいないことです。 以下はahmet alp balkan（@ahmetb）さんのKnative = Kubernetes Networking++を日本語訳したものです。この記事では、Kubernetes上のマイクロサービスを開発する中で発生する課題をKnativeがいかに解決するかが解説されています。Kubernetes Podcast #78 KUDO, with G
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1日300万件のレコードを処理するアーキテクチャ構成 保育士さんの負担はDesign for Failureな「午睡チェック」でサポート
コミューンのアーキテクチャ選定 - Commune Engineer Blog
Argo Rolloutsを導入してカナリアリリースを実現する - ZOZO TECH BLOG
Firebaseの導入を躊躇しているのはなぜ？モバイルファーストの考え方とは | Offers Magazine
新型コロナで休校になって暇になった高校生がミニサービス「Yobikake」を3日間で立ち上げた話 - Qiita
RendertronをGKEとCloud Runで構築しました - pixiv inside
BigQueryのオンデマンドクエリの利用量にフタをする (上限を設ける) - G-gen Tech Blog
GCPサービスで構築したインフラをAWSと比較してみる
「僕が今のピクシブのAWSやGCPの形を作ったと言っても過言ではない」 クラウド推進の生き字引が語る、これまでの取り組み
機械学習プロジェクト向けPipelineライブラリgokartを用いた開発と運用 - エムスリーテックブログ
Kubernetesをぶち壊す10の奇妙な方法 (後編) - Qiita
AzureやAWSの大規模障害でもサービスが停止しない設計とは
ゼロから始めるEKS事始め（前編） - Gunosy Tech Blog
ZOZOSUITの計測システムを支える技術的背景
Docker/Kubernetes便利ツール調査 - Qiita
GitHub Actionsの歴史（2021/12/1 更新） - cangoxina
本番で使えるFargate環境構築 - 虎の穴開発室ブログ
Knative = Kubernetes Networking++の全訳 - Qiita