CI/CD Conference 2021
数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021
CI/CD Conference 2021
スタートアップ企業向けインフラ運用入門（2）：ログ・メトリクスの収集
システム・サービスに関するログ・各種情報を取得する事により、トラブルシューティング、パフォーマンスチューニングのみならず、ビジネス上の成果の確認、UIの改善等にも役立ちます。ただ、闇雲に情報を取得しても、効果は上がらず労力ばかりがかかってしまいます。本記事ではログ・メトリクスの収集の目的を明らかにし、その為に必要な点を実例を挙げながら説明していきます。 「ログ」取得の目的 Retty開発担当の鹿島です。Webサービスに限らず、ITのシステムを運用していれば、何らかの形で「ログ」の取得・保存をしている事かと思います。そもそも、それらは何のために保存されているのでしょうか。まずは、「ログ」を保存する目的を明らかにし、その観点から各種の「ログ」について見ていきたいと思います。 開発や運用経験のある方であれば、 「ログにxxxに関する情報が出ていれば、障害解決がスムーズなのに......」 とか、
【CyberAgent】技術情報／TechReport - テックレポート／Amazon Web Servicesについて | 株式会社サイバーエージェント
概要 既存のインフラを利用しないで、「Amazon Web Services」（以後AWS）のみを利用し新規でサービス展開を行う場合に必要な情報、知識をまとめる。 注意 基本的な利用方法を除外し、実際の構築時に必要なトピックスに焦点をあて本ドキュメントを作成しました。 特にオープンに公開されている情報については割愛（Web及び書籍で多数公開されている情報）しています。 補足 本ドキュメントは、2012/08時点でのAWSで提供されているサービスを元に記述されています。AWSは日々新機能がリリースされていますので、利用する際は最新の情報を取得してください。 目次 概要 注意 補足 目次 序論 クラウドのメリット クラウドのデメリット AWSの製品・サービス構成 内容 アカウント管理 Consolidated Billing(一括決済) 使用例 作成手順 補足 AWS Support 補足 A
Dropbox のスケールとか
Python なサービス みんな大好き Dropbox のスケールとかメモ。以下のページ辺りからピックアップ。Parted? みたいなので、続編がでたら追記するかも。 Scaling lessons learned at Dropbox, part 1 (comment) Dropbox - Startup Lessons Learned (slideshare) Dropbox -Yコンビネーターが生んだスタートアップの軌跡と未来 - スケール関係ないですが、2006 年当時はオンラインストレージサービスがいっぱいあったようで、VC から資金調達したときのやり取りがおもしろい VC "クラウドストレージサービスなんて腐るほどある" Drew "なにか使ってるのありますか？" VC "NO" Drew "..." 完璧で、スケーラブルで、クロスプラットフォームなクラウドストレージ！当時、プ
スタートアップ企業向けインフラ運用入門（1）：監視 - O'Reilly Japan Community Blog
スタートアップ企業等の少人数チームの場合、専任のシステム運用担当がいることは稀だと思います。本記事では、そうした少人数チームの開発兼運用担当者を主な対象として、システム運用の重要な要素である「システム稼働状況の確認、障害対応」を省力化するための方法の一つとして「システムの監視」の方法について説明します。 少人数チームでのシステム運用 Retty開発担当の鹿島です。第1回で少し紹介しましたが、RettyはWebサイト、iPhoneアプリ、Androidアプリの計3プラットフォームを、3人＋αの開発者で開発を進めています。私は主にWebサイトの開発とインフラ全般を担当しているのですが、Webサイトの開発がメインのため、インフラ構築・運用に割ける時間はそれほど多くありません。 おそらく世間の小規模チームの大半では、我々と同様に専任の担当者がいないと思われます。今回の記事はそうしたスタートアップ企
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
My365の作り方 〜サーバ編〜
レンタルサーバが大好きなので、わざわざサーバを自分でどうこうしようとは思わないのですが、My365はサーバがネックになってサービスが正常に動かないということは避けたいと思い、今回はVPSを選択しました。 リリースまでとそこから2週間のサーバ環境の変化と失敗の記録です。Amazonへの移行から @takus 先生に加わってもらって、一人でやっていた時より安定したサーバ環境になりました。 (よかったらこちらもどうぞ → iOS編, iOS編, サーバサイドプログラム編 ) サーバ環境 ストレージサーバ: Amazon S3 WEBサーバ&データベースサーバ&etc: さくらVPS 8GB 写真だけはS3に置いて、あとは全て1台のマシンに載せてしまう作戦です。 写真をS3に置くことにしたのは、面倒なことを考えたくなかったからです。自分で管理するより明らかに安全で、容量が増えても問題なく、WEBサ
Pinterest のスケール
V 先生から教えて頂いたので、Instagram 同様 Django/AWS 構成の Pinterest のスケールをメモ。Pinterest はいつものアカウント名が初めて 先取 されたサービスなので、今後使わないと思います。 本題に入る前に、Python には The Zen of Python (日本語) という思想があります。私はこの思想を Python でのプログラミングだけでなく、インフラの構築の際も意識するように心がけています。"Simple is better than complex" です。Instagram や Pinterest のスケールを見て、この思想がもっと好きになりました。 Instagram はよりシンプルなインフラに更改していくことで、ただスケールするだけでなく、運用や変更のコストも最小限になるように最適化していると思います。結果的に Android ア
DevOpsとはどんなもので、何が議論されているのか（前編）
開発と運用の対立を越え、ビジネスのために協力し合う。「DevOps」ムーブメントをテーマにしたイベントが2月24日に都内で行われました。 IT業界がパッケージソフトウェアからオンラインサービスへと転換しつつある中で、優れたサービスを迅速に実現する重要なキーワードとしてDevOpsは注目されはじめています。 この記事では、日本でDevOpsの普及に努めている森川裕和氏(@nxhack)の講演をダイジェストで紹介しましょう。 眠れない管理者の悩みは世界共通 会場で、自分が運用の人は？（3割くらい）。では開発の人は？（8割くらい）。ではビジネスマンの人は？（2～3人）でも、これは全員のはずですよね。 これが今日のプレゼンの原点になります。 私はWebの運用やネットワークのBGPの運用までやっていたことがある、いわゆる「眠れないシステム管理者」でした。で、システムがスケールしないよね、とか、やっぱ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
