JVM勉強会（運用編）を開催しました - 株式会社ヘンリー エンジニアブログ
こんにちは、SREの戸田です。本日は社内で開催したJVM勉強会（運用編）の一部を公開します。 JVM、使っていますか？弊社ではサーバサイドKotlinが活躍しているので、もちろん日常的にJVMが稼働しています。このためサービス運用の一貫で必要になる知識や関連ツールなどをSREないしプロダクトチームに共有することを目的として、この勉強会を開催しました。 図1 勉強会はGoogle Meetでオンライン開催しました パフォーマンス・チューニング サービスを開発していると、この処理をもっと高速化したい！ランニングコストを抑えてユーザ体験の向上に投資したい！というというシーンには多く遭遇しますよね。こうしたユーザが増えてサービスに負荷がかかるようになったことで生じた課題に対して迅速に打ち手が取れることは、とても重要です。 しかし焦ってはいけません。「このコードはめっちゃループしてるし遅そう！」「あ
運用出来るWebアプリケーションの作り方
はじめに 先日、下記のようなツイートを見つけて、そういえば趣味で個人開発してたときには然程気にしてなかったけど、仕事で運用するようになって先輩たちから学んだり自分で身につけたチップスってちょこちょこあるよねー、とふと思ったので、Webアプリケーション開発に関わるものをいくつかまとめてみました。 特に体系的/網羅的という程でもないですし、最近はFWや色々な仕組みでカバーされてるものも多いですが備忘録として。 Tips 機械が読めるログを作る これは割と重要なのですが、ログは人間が読むものではなく機械が読むものです。それはZabbixだったりDatadogだったりSplunkだったりgrep/awkだったりツールは何でも良いのですが、古の時代はさておき現代ではログは機械が読めることが最重要です。 まず大前提として構造化されている必要があります。言うまでもないですが「フリーフォーマット」のログの
プロダクトオーナーの考えるべきところ - kawaguti’s diary
プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。 序盤戦、中盤戦、終盤戦の戦略 一番美味しいアイデアがでる可能性に備えるために 引き継ぎにはコストがかかるので人を追加すると遅くなる システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。 1. 序盤戦、中盤戦、終盤戦の戦略 「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユ
Javaでなぜ問題が起きるのか 〜システムをきちんと運用するための基礎知識 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
よく知らないアプリケーションの性能と戦わないといけないときの防衛術（前編） - Qiita
よく知らないアプリケーションの性能と戦う、という状況 SNSにキャンペーン載せたらバズってサイトがずっと503なんです、なんとかなりませんか？ バッチがいつもの時間に終わらないんですけど、急ぎ見てください！ みたいな連絡を、そろそろ帰るかと思った21時とか明け方5時とかに電話が鳴って受けることって、そこそこあると思うんです。 私が設計したわけでもなく開発したわけでもなく、レビュー参加とかで辛うじて全体は分かるけど、いまからソース見る時間もないし、開発した方は性能面の対処が覚束ない。突然性能面で火を噴いてなぜか自分が召喚されて2~3時間でどうにかしたい、という闇な状況にどういうふうに対応していたっけ自分、というのを経験則100%で書いてみようと思います。 この前編は道具の紹介(OS編)、中編は道具の紹介(Java)、後編は道具の紹介(PostgreSQL)です。 中編 → https://q
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバーレスJavaの今 ~SnapStartとWeb Adapterを寄せて~