AWSとGCPでマルチクラウドインフラを始めた話。複数回連載予定の第一回です!
Kyoto.js 12発表スライドです。 https://speakerdeck.com/fand/hurontoendonizhi-xu-woqu-rili-sufang-fa の続編です。
遅めですが明けましておめでとうございます。そんな感じで。 基本的に社内向け。あとは特定のお客さん向け。 自分の意見を詳記しとく。あとこれは日本の話で、海外の状況は知りません。 ■「パブリック」クラウド ここでは、大規模メガクラウドを指す。よって、AWS・Azureあたりを考えている。国内クラウドとは明確に規模・技術力で差がついており、はっきり分けるべきと思っているので、ここではAWS・Azureとしている。多分SalesforceとかIBMのやつも入るとは思う。Googleのクラウドについては技術はぶっちぎりだけど、一般民間人には意図していること天才すぎて理解できる気がしないので範囲外とする。 基本的に「所有より利用を」コンセプトにし、使いやすさと低コストを全面に打ち出し、トレードオフとして共有故の仕組み/運用の「ある種の不透明性」を要求する仕組み。なお、不透明性ってのは、これは提供者の企
ドメイン駆動と言っても、データを永続化している以上、ドメインレイヤがインフラレイヤを活用する必要があり、ドメインがインフラに依存するアーキテクチャはごく自然のようですが、DIP(dependency inversion principle)を実現したアーキテクチャでは、インフラがドメインに依存するようになり、従来のアーキテクチャとは依存関係が逆になります。 伝統的なアーキテクチャ → ドメインレイヤがインフラレイヤに依存 DIPを実現したアーキテクチャ → インフラレイヤがドメインレイヤに依存 この逆転のアーキテクチャをどう実装したらいいか疑問に思っている人も多いのではないでしょうか?Amazon.co.jp: 実践ドメイン駆動設計 (Object Oriented Selection): ヴァーン・ヴァーノン, 高木 正弘: 本で紹介されている実装方法をScalaで説明します。 実装のポ
こんにちは。 インフラエンジニアの村上です。 マネーフォワードのインフラチームは、サービスに関わるインフラから、自社の作業環境、開発環境、さらにはサービスのインフラの中でも物理的なものからOS・ミドルウェア・アプリケーションのメンテナンス・ビルド・リリース・運用まで幅広く関与しています。 今回はGoogle Cloud PlatformのBigQueryを活用してアクセスログの分析環境を構築した時の話を紹介します。 この記事に書かれる事 データ分析基盤としてBigQueryを使用した話と データ量を例示しながら使用を開始した時のトラブルシュートとパフォーマンスについて紹介する。 データ移行のコツもうまく含めながら書いていく。 BigQueryを採用した訳 マネーフォワードの家計簿は350万人以上のお客様に利用いただき、 アクセスログは日々2.500万件程度増えております。 サービス開始から
@ymmt2005 こと山本です。 今回は開発本部と運用本部のメンバーが協力して進めている cybozu.com やサイボウズ Live のアーキテクチャ刷新プロジェクト「Neco」について紹介します。 Neco を 3 行で説明すると、 サイボウズのクラウドインフラのいけてないところを洗い出して、 5 年程度を目安に改善するつもりだけど、 やりたいことが多すぎるので、We are hiring! で済んでしまうのですが、それだけでは面白みに欠けますので、いけてない内実を暴露しながら解説いたします。 サイボウズはクラウド 5 年生 正確に言うとサイボウズ Liveなど一部のサービスはもっと以前から取り組んでいたのですが、本格的にクラウドサービスといえるインフラを構築してサービス提供を開始したのは今から 4 年前の 2011 年 11 月となります。そこでオープンしたのが cybozu.co
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
追記:openssh-7.3 以降なら ProxyJump や -J が使えます ホスト名を + で繋げることで多段Proxy接続も簡単に、がコンセプトだった本エントリの設定ですが、OpenSSH 7.3 から ProxyJump という設定が使えるようになったので、使えるなら ProxyJump を使う方が健全だし柔軟で使い勝手も良いのでそちらを覚えて帰ることをオススメします。 使い方は簡単で以下のような感じです。多段も行けるし、踏み台ホスト毎にユーザ名やポート番号を変えることも出来ます。 # 1. bastion.example.jp -> internal.example.jp ssh -J bastion.example.jp internal.example.jp # 2. bastion.example.jp -> internal.example.jp -> super-de
ホームページ20158月24YAPC::Asia Tokyo 2015で開発・運用業務改革に関する発表をしてきました&感想 #yapcasia #yapcasiaE 今年もYAPC::Asia Tokyo 2015へ行ってきました、そしてトークしてきました! 僕も @uzulla さんのようなノリノリの3日間を過ごしました! (このあと、uzullaさんは一発目のトークを始めるのでした。) いやー、楽しかった!今年でひと区切りとなってしまうのが本当に惜しいです。さて、ブログを書くまでがYAPCですので、ブログを書いてYAPC、そして僕の夏を締めることにします。 「辛いことをやめる!から始まる業務改善とInfrastructure as Code」と題してトークしました (写真は公式カメラマンさんによる撮影です。ありがとうございました!) 足を運んでくださった皆様、どうもありがとうございまし
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
自己紹介 モデレータ @deeeet 登壇者 @catatsuy @okkun @y_uuk1 @rrreeeyyy wakateinfra 新卒入社3年以内のインフラエンジニアで集まったコミュニティ 今回のセッションの目標・ゴール 若者は今のインフラ界隈をどう思っているのか 質問について #wakateinfraのツイートを拾います agenda 自己紹介 技術トレンドについて 技術習得について 今後のキャリアについて まとめ 技術トレンドについて Infrastructure as Code JTFで長らく語られてきたテーマ 息を吐くようにコードを書いてきた世代 プロビジョニングツールの良い所、悪いところ コンテナ 事前アンケートより Chefかpuppetを使っている とりあえずAnsibleを触っている Itamaeも触り始めている @rrreeeyyy 構築を担当する人によって違
こんにちは、テコラス株式会社技術研究所の伊勢です。この度、テコラス::データホテルテックブログが開設されたようでして、「最初のエントリは最年長技術者が書くべきじゃねーか?」というデジコアディレクター松本氏からの脅迫に近いお達しにより、一発目のエントリを書くことになりました。とはいえ、最近あまり仕事もしておりませんし、旬な技術や実装ネタも無いため、どーしよーっかなー?と考えていましたら、技術評論社Software Design誌編集長の(心やさしい)池本さんから、過去に寄稿した記事を転載してもイイヨ!というありがたいお言葉を頂きましたので、それを元に書きたいと思います。 本エントリは昨年12月4日に技術評論社から発売されたSoftware Design別冊シリーズ「インフラエンジニア教本」に寄稿させて頂いた「インフラエンジニア鬼十訓」を転載したものです。この鬼十訓は私の経験知見だけではなく、
Google Cloud Platform (GCP)の英語ブログに、Google Compute Engine (GCE)のライブマイグレーション機能について解説記事がポストされた。個人的にもいくつかの大規模な案件でこの機能の能力に触れて、GoogleまじGoogleだなと思わされたし、GCPチームで実際に作った人たちと会うととても誇らしげに説明してくれる。熱いのだ。そこで、上記ブログ記事+個人の経験をもとに簡単にまとめてみたい。 なお、以下の内容は個人の感想です! Heartbleedバグの時もVM再起動なし GCEでは2013年12月より、ライブマイグレーションを利用したTransparent Maintenance(自動メンテナンス)という運用を開始している。これはつまり、VMを動かしたまま同一ゾーン内の別のサーバーへ移動することで、ハードウェアやホストOSのメンテナンスを勝手にや
インフラ部の荒井(@ryot_a_rai)です。この記事ではクックパッドで利用しているプロビジョニングツール "Itamae" の紹介と細々した Tips を紹介します。 式年遷宮とプロビジョニングツール 現在、弊社ではインフラの式年遷宮*1を進めています。式年遷宮以前、弊社では Puppet を利用してサーバをセットアップしていましたが、式年遷宮に際して既存のプロビジョニングに関するコードは捨てることになるため、プロビジョニングツールの再検討を行うことになりました。 Puppet, Chef, Ansible, SaltStack を検討した結果、 言語特性の観点では、Ruby DSL な Chef が良い アーキテクチャ・エコシステムの観点では、シンプルな Ansible が良い といった点から、どれも決め手に欠ける状況で、Ruby DSL で記述できるシンプルなプロビジョニングツール
社内勉強会でいろいろ教えてもらったのでメモ。トレンドと呼ぶには一、二年遅い。なお自分の考えを整理するために書いているものなので正確さは保証しませんしツッコミも不要です。 前提: 仮想マシンと仮想マシンイメージ VirtualBox とか、 AWS なら AMI とか。ホストマシン上で動作しているものが仮想マシンで、仮想マシンイメージは仮想マシンのスナップショットだったり、それをもとに新しい仮想マシンを作れる雛形だったり、くらいに理解しておけばよい。 Vagrant と Packer 仮想マシンと仮想マシンイメージの技術があるおかげで、作業環境(Mac とか Windows とか)上でプロダクション環境により近い環境を手軽に用意できるようになた。しかし仮想マシンの管理(起動したり、設定を変えたり)は手作業でやる必要があった(VirtualBox なら GUI でぽちぽちやったりとか) Vag
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
はじめに このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。 まとめ 昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。 クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。 そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。 発表資料&箇条書きで振り返る最近の動き AWS Casual Talks #3 https://github.com/myfinder/aws-casual-3/blob/master/slide.
Eliminate duplicate support tickets & clunky email lists Halt the flood of support requests during an incident with proactive customer communication. Manage subscribers directly in Statuspage and send consistent messages through the channels of your choice (email, text message, in-app message, etc.) Display the status of each part of your service Control which components of your service you show o
DockerはIT界隈で広まりつつも、なかなか実践的に使うことができないという人は多いのではないかとかと思います。しかし何もサーバ運用環境として使わずとも、使いどころはあります。その一つがサーバソフトウェアのインストールです。 サーバソフトウェアはインストールの手間と、その後のバージョンアップや他のソフトウェアで使っている共通ライブラリのコンフリクトなど、とかく運用が面倒です。基幹系システムが入っているサーバに他のソフトウェアをインストールするのは躊躇しますよね。 そういったときにDockerを使えばそれぞれのソフトウェアの環境が分けられるのでセキュリティ、運用的に安心できます。今回はその一つとしてDocker Selenium、Dockerを使ったSeleniumサーバを紹介します。 Docker Seleniumのインストール インストールはとても簡単です。なおDockerはインストー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く