全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
問い合わせ率が3年間で半分になった
こんにちは。カンムで業務部長してます平湯（ひらゆ）です。 カンムは現在、Visaプリペイドカードの「バンドルカード」と手元の資産形成に活用できるクレカの「Pool」の2つの事業をやっています。今回はバンドルカードのお話です。 2022年末に過去の問い合わせ率を集計したところ、一番多かった時期と比べると問い合わせ率が半分になってました。（問い合わせ率 = 問い合わせ数 / 稼働会員数） 良きタイミングなので頑張ってきたことを振り返ってみます。 どんなことをやったか一次情報から課題特定 →問題提起 →オペ整備 →リリースのサイクルを回した結果です。何よりも一次情報の取得が大事です。時間がかかるし、単純作業なので苦しいんですが、生の声を読むことで感情や背景が頭に染み込みます。問題により深く入り込めているという感じでしょうか。 この課題の解決策をエンジニア・デザイナー陣と考えていきます。カンムはエ
WebAPIを構築する際にAPI Gateway+Lambdaを選択するべきか？
はじめに このツイートに結構反響があったので、雑になるがとにかく自分の考えをダンプする。もともと書いていた記事はうっかりやらかしてデータロストした、泣きたい。 話をわかりやすくするために、ALB+ECS（Fargate）を使ってWebAPIと対比して説明しているが現実はもっと複雑である。 引用リツイートをもらえた部分などについてもアンサーっぽいことも書いていく。 AWS利用費と人件費の話 AWS上にWebAPIを構築する際に、AWS利用費の削減をモチベーションとしてApiGW+Lambda構成が、採用されることがある。確かにAWS利用費は下がるがApiGW+Lambda構成を設計〜運用するためにはAWSに関する知識の中でもとくに専門的な知識が必要になる。こういった人材を雇用または外部へ発注し続けることは人件費に跳ね返ってくる。 ApiGW+LambdaがWebAPIのための構成として唯一無
「運用組織」の考え方と設計 〜 運用組織論 2021 / 20210310-ssmjp-operation-organization
ssmjp ssmonline #8 "第三回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/206074/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
暗号鍵管理ガイドライン | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
実際の暗号システムがセキュアに動作し続けるためには、暗号アルゴリズム自体がセキュアであるだけでは不十分で、データが保護される期間中、その暗号アルゴリズムが使用する暗号鍵もセキュアに管理されている必要があります。そのため、暗号鍵やデータのライフサイクルを踏まえた運用、安全な暗号鍵の保管、暗号鍵危殆化時の対策などを行う上で参考となるガイドラインを取りまとめています。 「暗号鍵管理システム設計指針（基本編）」の内容 「暗号鍵管理システム設計指針（基本編）」は、あらゆる分野・あらゆる領域の全ての暗号鍵管理システムを対象に、暗号鍵管理を安全に行うための構築・運用・役割・責任等に関する対応方針として考慮すべき事項を網羅的に提供し、設計時に考慮すべきトピックス及び設計書等に明示的に記載する要求事項を取りまとめたガイドラインとして作成されたものです。 具体的には、暗号鍵管理の必要性を認識してもらうために「
どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング
Platform チームの@deeeeeeeetです． Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです．Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています．立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました． チームのメンバーが増えるほど1チームとして動くには限界がきており，またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました．これらの課題を解決するために組織変更を行い，Platform チームを複数の専門性に特化したチームに分割しました． 本記事ではチームのデザイン，チームが分離しても独立性を保ちつつ
Kubernetes 運用設計ガイド / A design guide for Kubernetes in production (Japanese)
2018/04/19 JAPAN CONTAINER DAYS V18.04 (https://containerdays.jp/) にて発表したものを加筆修正しました。 Abstract: Kubernetes は豊富な機能とその高い拡張性により、現実における様々なユースケースに対応できる一方、その多機能さゆえにどう使えば良いか迷っている方もいると思います。Kubernetes の基本を学んだ人や本番運用を始めた人を対象に、私がメルカリでの Kubernetes 本番運用経験を元に考えた、アプリケーション運用、インフラ運用、組織の 3 つの観点での設計の指針を紹介します。
バッチ処理、ジョブ管理について書いてみる - wyukawa's diary
僕はHive, Pythonでバッチ処理を書いてAzkabanでジョブ管理するシステムを構築、運用した経験が2年ほどあるので今日はバッチ処理、ジョブ管理について書いてみようと思います。 僕の経験上Hadoop特有の部分、例えばテスト環境が作りづらいとかバッチサーバーはジョブをsubmitするだけなので負荷はそんなにかからないとか、はあるけれど割と汎用的なのではないかと思います。そもそもバッチ処理、ジョブ管理について書かれたものはほとんど見た事がないので参考になれば嬉しいし、こういう良い方法もあるよ！とかあれば是非ブログ等に書いてほしいと思っております。 最初に言っておくとバッチ処理、ジョブ管理において重要なのは障害時のリカバリのしやすさです。正常時はまあいいでしょ。 なので例えば引数に日付を持てないようなバッチ書いたら辛いですし、LL言語で書く方がコンパイル、パッケージングとか楽です。CP
コンシューマサービスの運用に耐えるDB性能設計とは - レベルエンター山本大のブログ
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の３つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ！「hiromi と楽しむOracleパフォーマンスチューニング！」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
米Yahoo!がシステムダウンしない5つの理由
昨年の10月14日、米Yahoo!のトップページがダウンしたと、米Huffington Postが記事「Yahoo DOWN: Yahoo.com Outage Reported」で伝えました。米Yahoo!にとってトップページがダウンすることはきわめてまれなことで、この件が発生するまでほぼ10年にわたりトップページのダウンは起きていなかったと言われています。 その米Yahoo!はシステムダウンを防ぐためにどのような取り組みをしているのか？ 米オライリーが主催したイベント「Velocity 2011」で、Yahoo!サービスエンジニアリング部門のVice President、Jake Loomisが行ったセッション「Why the Yahoo FrontPage Went Down and Why It Didn't Go Down For up to a Decade before Th
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
バッチアプリケーション設計のポイント
データベースの運用に当たって、効率のよいバッチアプリケーションが作成できるかどうか、は大きな課題です。本連載では、Oracle Databaseの管理運用を前提に、効率のよいバッチアプリケーション作成のためのテクニックを紹介していきます。 バッチ処理の抱える問題 オープン系技術の導入によって、企業システムのフロントエンド（画面周り）は大きく進化を遂げました。しかし、バックエンド（サーバ周り）でのバッチ処理は、今日でもさまざまな問題を抱えています。 最も深刻な問題は、バッチの処理性能が著しく低下してしまうことでしょう。業務のIT化が進むにつれて、データベースに蓄積されるデータ量はどんどん増加する傾向にあります。また、Webなどで多様なサービスを展開するには、データをさまざまな形式に加工／集計する必要があります。 この2つのマイナス要因によって、既存のバッチアプリケーションにかかる負荷はますま
グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shiodaifuku.io
なめらかなシステムのアイデアと設計概要 / namerakad-idea-design
システム監査制度の改訂について