読者です 読者をやめる 読者になる 読者になる

まいんだーのはてなブログ

はてブなのはてブロなのどっちなの

ISUCON6参加者が実践したInfrastructure as CodeあるいはISUCON6のAzureインフラ解説

ISUCON6予選参加者の皆様、お疲れさまでした。
今回の ISUCON は Microsoft Azure ということで、多くの方にとってなじみのない環境だったと思います。

そこで、今回の ISUCON6 の予選問題がどのような仕組みで展開されているのか、Azure IaaSの仕組みを交えて解説します。

はじめに

@matsuuさんの多大な努力によって、運営に提案しようと思っていた構成の大半がすでに作られていました。
使ったことのないクラウドを触り始めてすぐに作り上げてしまうのは、さすがです!

復習される際はぜひ、@matsuuさんの作ったテンプレートを活用するとよいでしょう。

Azure IaaSの概要

Azureはおおむね国ごとにジオという単位で分けられており、その中に2つ以上のリージョンを持っています。
リージョンはそれぞれペアになるものが存在していて、日本では東日本と西日本がそれぞれペアリージョンになります。
そして、リージョンの中には複数のデータセンターが存在するという構成です。
f:id:myfinder:20160918132458p:plain

データセンター内では、物理サーバの配置を"クラスター"という単位で配置しています。
クラスターは同種のハードウェアの集まりで、例えばXeon E5-2673 v3の乗った10G NICのサーバなど、スペックが統一されたものです。
ユーザが仮想マシンを起動すると、裏側では "ファブリックコントローラ" と呼ばれるものが、その仮想マシンをどのクラスターに配備するかを決定します。

仮想マシンをファブリックコントローラが配備することを "デプロイメント" と呼び、これは一つのクラスターを対象に配備が行われます。デプロイメントはクラスターを跨ぐことはありません。
デプロイメントは、リソースマネージャーモデルの仮想マシンであれば、後述の "可用性セット" 単位で1つのデプロイメントとして扱われます。

f:id:myfinder:20160918135925p:plain

これは管理画面にも一切出てこないもので。通常ユーザはこのクラスターを意識することはありません。
ユーザがクラスターを意識するタイミングがあるとすれば、インスタンスタイプ変更の時です。

クラスターは "同一スペックのサーバの集合である" と説明した通り、インスタンスタイプの変更はこのクラスターの範囲の中で行うことになります。
ですので、最初にAシリーズなどの古めのスペックのインスタンスタイプで仮想マシンを作ると、古いクラスターに着地することになり、その後Dシリーズへ変更するにはVMを一度削除する必要があります。

f:id:myfinder:20160918134715p:plain

クラスター内部の構造

クラスター内部では "障害ドメイン" という単位で電源やネットワーク機器が配置されていて、これらの装置の障害がほかの障害ドメインに影響を及ぼさないように設計されています。ひとつのクラスターは、数十の障害ドメインで構成されています。

先に少し触れた "可用性セット" ですが、仮想マシンのメニューにそういうものがある事に気付いた人もいるかと思います。
これは、複数の仮想マシンを同一の可用性セットに入れると、最大で3つの障害ドメインに分散配置されるようになるものです。
f:id:myfinder:20160918141159p:plain

Azureの各種サービスはこれらの基盤の上に成立しています。

Azureにおけるリソース管理の概念

ISUCON6予選では "Deploy to Azure" ボタンを押して "リソースグループ" を作成し、その中に仮想マシンやネットワーク、予約済みIPといった "リソース" を展開しました。
Azureにおけるリソース管理はこの "リソースグループ" という単位で複数のリソースを行うのが基本です。
f:id:myfinder:20160918151204p:plain
Azureにおいては全てのものがリソースであり、必ずどこかのリソースグループに属します。
リソースグループは図にある通り、リージョンを超えて広げることができます。もちろん海外のリージョンでもOKです。
リソースへのアクセス制御は、リソース、リソースグループごとにアクセス制御(IAM)で設定をすることができます。
f:id:myfinder:20160918152120p:plain
これとは別に、タグも存在しています。タグはリソースに対して "キー = 値" 形式で付与することができます。
例えば "所属プロジェクトAに属するリソースグループ" とか "本番環境である" とか、そういった分類をするときに利用します。
f:id:myfinder:20160918154210p:plain

ISUCON6予選で皆さんが行った "Deploy to Azure" の仕組み

Azureではリソースを宣言型のテンプレートを用いて管理しています。
ポータル画面から何かのリソースを作った場合、裏側ではすべてテンプレート定義として生成され、管理されています。
逆に言うと、独自のテンプレートを定義して、それを読み込ませることも可能ということです。

今回のISUCON6予選ではこの手法を用いて、運営の用意したテンプレートを各自のAzureアカウント内へサーバ環境をデプロイする手法を取りました。
下記が、そのテンプレートの基本構成です

{
   "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "",
   "parameters": {  },
   "variables": {  },
   "resources": [  ],
   "outputs": {  }
}

テンプレートの要素詳細はドキュメントを見ていただくとして、定義の中で特に重要なのが resouces セクションです。
resouces セクションでは、作成若しくは更新されるリソースを定義します。と、書いてもわかりにくいと思うので、実際の仮想マシンの定義内容を見ていきましょう。

{
      "type": "Microsoft.Compute/virtualMachines",
      "name": "[parameters('vmName')]",
      "apiVersion": "2015-06-15",
      "location": "[variables('location')]",
      "tags": {},
      "properties": {
        "hardwareProfile": {
          "vmSize": "Standard_D2_v2"
        },
        "storageProfile": {
          "imageReference": {
            "publisher": "Canonical",
            "offer": "UbuntuServer",
            "sku": "16.04.0-LTS",
            "version": "latest"
          },
          "osDisk": {
            "name": "[concat(parameters('vmName'), '-os')]",
            "createOption": "FromImage",
            "vhd": {
              "uri": "[concat('https', '://', variables('storageAccountsName'), '.blob.core.windows.net', '/', variables('commonName'), '/', parameters('vmName'), '-os.vhd')]"
            },
            "caching": "None"
          }
        },
        "osProfile": {
          "computerName": "[parameters('vmName')]",
          "adminUsername": "[variables('adminUsername')]",
          "customData": "BASE64Encoded-userdata",
          "linuxConfiguration": {
            "disablePasswordAuthentication": true,
            "ssh": {
              "publicKeys": [
                {
                  "path": "[concat('/home/', variables('adminUsername'), '/.ssh/authorized_keys')]",
                  "keyData": "[parameters('sshPublicKey')]"
                }
              ]
            }
          },
          "secrets": []
        },
        "networkProfile": {
          "networkInterfaces": [
            {
              "id": "[resourceId('Microsoft.Network/networkInterfaces', parameters('vmName'))]"
            }
          ]
        }
      },
      "resources": [],
      "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountsName'))]",
        "[resourceId('Microsoft.Network/networkInterfaces', parameters('vmName'))]"
      ]
    },

"type": "Microsoft.Compute/virtualMachines" 部が仮想マシンを表す記述です。Azureで提供されているtypeはCLIの "azure provider list" コマンドで確認することができます。
"name": "[parameters('vmName')]" 部はその名の通りこのリソースの名前を定義する部分です。parametersは運営の用意したテンプレートにあるparametersセクションに記述されたものを指定しています。
locationはvariablesセクションにある "location": "[resourceGroup().location]" という記述の通り、そのリソースグループが定義されたロケーションに合わせる設定になっています。
"properties" で、それぞれのtypeが要求する属性を指定していきます、仮想マシンの場合は "仮想マシンタイプ" "ストレージ設定" "OSプロファイル" "ネットワーク設定" "依存しているリソース" が主に設定を必要とする項目です。

この定義で仮想マシンが立ち上がるわけですが、実際のプロビジョニングは別に走ります。その指定をしているのが "osProfile" -> "customeData" です。
ここにBASE64エンコードしたスクリプト(今回はbashスクリプト)を書いておくことで、起動後にcloud-initによってプロビジョニングする形です。

#!/bin/sh
# init script for isucon6-qualifier

set -ex

export DEBIAN_FRONTEND=noninteractive
apt update
apt install -y --no-install-recommends ansible git aptitude
apt remove -y snapd

cd /tmp &&  wget -O- https://isucon6qimage.blob.core.windows.net/isucon6q/isucon6-qualifier.tar.gz | tar zxvf -
cd /tmp/isucon6-qualifier/provisioning/image/ansible
PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ansible-playbook -i localhost, *.yml --connection=local -t prod
cd /tmp/isucon6-qualifier/provisioning/image
./db_setup.sh
cd /tmp && rm -rf /tmp/isucon6-qualifier && rm -rf /tmp/ansible-tmp-*
shutdown -r now

こういうJSONを書く時に、どういう構成になっているか視覚的に見られる方が良いでしょう。そんな時はARMVIZを使うと、図のようにどんな構成になっているかを可視化できますので、Azureでインフラ構築をする際にはぜひ活用してみてください。
f:id:myfinder:20160918184557p:plain

作成したJSONは、どこかパブリックな場所に置いて https://portal.azure.com/#create/Microsoft.Template/uri/ にエスケープしたURLを渡すか、Azureポータル管理画面の "テンプレートのデプロイ" から投入することもできます。
f:id:myfinder:20160918192239p:plain
他にはAzure CLIのコマンド "azure group deployment create -f " でもデプロイ可能です。

今自分が使っている環境の設定がどうなっているかを見たい、という場合 https://resources.azure.com/ にアクセスすると、閲覧可能なサブスクリプション配下の設定状況を見ることができるので、一度見てみると良いでしょう。

うぇー結局JSONかよめんどくせ〜と思ったあなたへ

AzureといえばMicrosoftが提供しているわけですが、MicrosoftといえばVSCodeも提供しているわけでして、このテンプレートもVSCodeで書くことができます。
azure.microsoft.com
このページに書いてある通り、"ext install azurerm-vscode-tools" すれば、補完を効かせて記述することができます。
VSCodeにはTerminalが統合されているので、そのまま "azure group deployment create -f " で手元からクラウド側に反映させることができるので、portalを触ることなくどんどんデプロイできます。

付録: ストレージアカウント?

初めて仮想マシンを作ったとき、"ストレージアカウント" という言葉が出てきて "???" となった方は多いのではないでしょうか。
Azureのストレージコンセプトは、ストレージサービスの中に複数の機能が存在する構成になっています。
f:id:myfinder:20160918155104p:plain
そして、そのストレージアカウントは、コンテナ―という箱と、その中に作られるVHDやTable、Queueで構成されています。
f:id:myfinder:20160918155224p:plain
単純なハードディスクサービスのようなものは今のところないので、この概念を頭の片隅に置いておいて下さい。

ひとりじゃなくてみんなで使うためのgolangの本 "みんなのGo言語"

9/9(金)発売の "みんなのGo言語" を Daisuke Maki (@lestrrat) | Twitter さんから頂戴しまして、一足先に読むことができました。感謝を込めて感想を書かせていただきます。

みんなのGo言語[現場で使える実践テクニック]:書籍案内|技術評論社

本書のカバー範囲と対象読者

本書はいわゆる "これからGoを始めたい" 人向けの本ではありません。 A Tour of Go でできるような最初のイロハはカバーされていません。 すでにGoを多少触り始めていて、一人だけで書くのではなく、周りの同僚や仲間など複数の人間が関わる環境でどのようにGoを活用していくべきかの指針をまとめたものと捉えると良いでしょう。 もちろんこれから始めたいという人に対して役に立たないわけではありませんので、特にチーム開発運用にGoを取り入れたいと考えている方には得られるものが多くちりばめられていると思います。

一通り読んだ所感

前述の通り、本書は第1章から "チーム開発" という言葉が出てくる通り、個人がひっそり写経するものではなく、多くの人どうしでGoを使った開発をしていくために "チーム開発の始め方" "マルチプラットフォーム対応" "実際のアプリ/CLIツール開発の実践" "テスト" "ハック的な黒魔術" まで幅広くテーマを扱っているので、広い視野を持って読むとより著者たちがこれまでの実運用でどのようなことを考えてGoを使ってきたか見えてくるのではないでしょうか。 特に3章はバージョン管理からチューニングまでをカバー範囲としてまとめられており、また、6章では長く運用を続けていくために必要なテストの手法が実践的にまとめられています。 私は普段、仕事でGoを書く立場ではありませんが、もし使う機会があればこの書籍を片手に実践していこうと思います。

おわりに

"みんなのGo言語" はその書籍名の通り、ひとりではなくみんなで使うときにどのように対応していけば良いか、著者一同の実践ノウハウが詰まっています。 著者一同が実践してきた内容や良いとされていることを一通り押さえており、ページ数も多すぎないので気軽に読むことができます。

もしあなたが "なんとなく気になってるんだけどどうやって使ったら、導入していったらよいだろう" とお悩みの場合は、本書は良いGoライフを得る一助となるでしょう。

最後に重ねまして @lestrrat さん、ありがとうございました。

クラウドを使い始めた初心者が脱初心者へ向けた第一歩を踏み出すための一冊

俺たちのリーダーこと @iara さんが著者に名前を連ねている、Amazon Web Services 実践入門を発売前に頂戴することができたので、御礼を兼ねて感想などをまとめさせていただきます。

twitter.com

www.amazon.co.jp


本書のカバー範囲と対象読者

本書は入門本と銘打たれている通り、IaaSと一部のマネージドサービスを紹介しつつ、UIとCLI両方での操作がまとめられています。
オンラインマニュアルにも同様のことは書かれているわけですが、本書では実際に手を動かしてみるにはこうしましょう、という切り口でまとめられているので "クラウドをこれから使いたい、でもどうやって触ったらいいかわからない" という人がまず写経的にやってみるのに適していると感じました。
他にも、 "今AWS使っているんだけどUIからポチポチとやっているだけだよ" という方がもう一歩深い使い方を学んでいくというところでも役立つと思います。
そういった側面が強いため、手順をまとめたマニュアル集といった趣になっており、事例や深く突っ込んだ使用法については言及されていません。

読んだ所感

リーダーの書いた5章を読んだ時に、"最近はむしろこういうネットワーク設計とかしなくなってきたな" と思ったところが気づきというか振り返りがありました。
従来のクラウド活用は、物理サーバとネットワークの設計をクラウドに持ち込んで再現するといった向きが多かったと思います。
自分自身がいち技術者としてクラウドを触り始めたのはIaaSであり、やはりそういった "既存技術をうまくIaaSに合わせていく" アプローチで作っていました。
最近のクラウド利用はそのようなVMを並べるところから徐々に、PaaS/SaaSを組み合わせてサービスを作る流れになってきています。サーバーレスアーキテクチャとか言われているようなやつですね。
PaaS自体はSalesforceGoogleのApp Engineに代表されるようなサービスが既に7年前くらいにはあったわけですが、その利点が広く取り沙汰されるようになってきたのはここ1〜2年かなと。
"as a Service" をうまく組み合わせてサービスを作る際には、IaaSでやっていたようなネットワーク設計は(PaaS/SaaSの陰に隠れて見えなくなり)利用者が考慮する必要がなくなるわけです。

とは言え "我々はクラウドフリーで常にVMと仮想ネットワークしか使いません" という主義の会社もあれば、"うちではas a Serviceをうまく組み合わせる人のことをインフラエンジニアって呼ぶよ" という会社もあるので、すぐに見えなくなるものでもないし、ましてネットワークの技術自体が無くなることはあり得ないのだけれど、うっかりすると触れる機会がどんどん少なくなっていくものになるなと。

そういった流れの良し悪しについては色々な言説ありますが、何を選べばよいかを判断できるような人材になったほうが、著者の言う "もっと生産的で有用な時間を確保できる" ようになると考えます。

おわりに

"Amazon Web Services実践入門" はAWSを使い始めた初心者が脱初心者へ向けた第一歩を踏み出すのにちょうど良いでしょう。
今の時代、"How"はAWSに限らず掃いて捨てるほど存在しているので、適切に選びとってサービスを作っていけるステップとして本書を使うと有意義だと考えます。

最後に、本書を贈っていただきました @iara さんに感謝申し上げます。ありがとうございました。

JAWS-UG Meguro #2 で "今更聞けないストリーム処理のあれとかこれ" というLTをしました。

最近はAzureをよくさわるんですが、AWSも引き続きホットなのでJAWS-UG Meguro #2へ行ってきました。
単に行くだけというのも面白くないので、最近いろいろ調べているストリーム処理回りについて一度整理しておこうということで、基盤と技術選択についての簡単なまとめをLTしたのでここに貼っておきます。

www.slideshare.net

これから始めたい人で、よくわからないけどとにかく始めて何かしら可視化したいという人は引き続き Azure Stream Analytics をお勧めします。

次回テーマは運営のAWS SAの方に希望を言うと良いそうです。
個人的にはAWS上でのネットワーク設計とかいろんな人の話を聞いてみたいかなと思ったりします。

YAPC::Asia 2015でAzureの話をした件とハッカソンの運営をした件

YAPC::Asia 2015 での発表

  • Discover the Microsoft Azure と題して、Azureの特徴ある "as a Service" の紹介と、その基盤について入門的な発表をいたしました。
  • 以前 "今後は複数クラウド事業者が提供するサービスを組み合わせて開発する流れが加速する" と書いたかと思いますが、各社特徴あるサービスがどんどん出てきており、かなり選択の幅は広がってきたと思います。
  • 今回紹介したPowerBIなんかを試してみたいという方は、下記の記事をご覧いただくのが手っ取り早いかと思います。 qiita.com

ハッカソンの運営

  • 2013年にも運営をさせてもらったわけですが、今回はGitHubさんの協力もあって、内容がかなり充実したものになりました。
  • YAPC::Asia 本編でトークのあった、Ben OgleさんのElectron話と、mizchiさんの開発話(から発展して逆質疑応答になっていたのは面白い展開でした)
  • 普段交流のない人とも交流ができて、いろいろとインプットを得ることができました。

所感

昨年 YAPC::Europe に参加した話をしたところ、今年は日本から8名(‼)参加するとのことで、いい流れだなと思います。 これまでの運営形態でのYAPC::Asiaはいったん終了という話ですが、builderscon.ioの発表もあり、カンファレンスは今後も盛り上がっていくといいなと思いますし、微力ながら協力できることは積極的にしていきたいです。

牧さんをはじめ、スタッフの皆様、とても良いイベントをありがとうございました。 過去最大の会場規模でも平和裏に進んだのは凄いことだと思います。

個人的なハイライト

  • SUZURIさんとmotemenさんの発想が完全に一致 f:id:myfinder:20150824114842j:plain

Microsoft に入社しました

失業エントリからはや1ヶ月、新しいチャレンジとしてこの5月から Microsoft で働くことにしました。

前職では "どスタートアップ" からいっぱしの上場企業になるまでのサービス基盤をやり遂げることが出来ました。

が、ここ半年ちょい、運用系仕事を減らしていた最中は “開発シフトしていきたい” みたいなことを思ってはいたのですが、失業して時間ができたので改めて振り返ってみて思い直したのは “自分はやはり基盤側の方により興味関心が強い” ということでした。
また、ハウジングの物理基盤から IaaS + SaaS へ移行させる取り組みをして感じたのは “開発技術や運用基盤の選択は生産性と俊敏性をより重視すべき” というものでした。

実際 AWS で EC2 を使っているユーザが BigQuery で集計/分析したりするような事例は沢山出てきており、SaaS, PaaS をウマイこと組み合わせてサービスを構築する流れがますます加速するでしょう。

そういった考えに立つと開発技術から運用基盤であるクラウド、果てはコンテンツ配信基盤まで持っていてサービスライフサイクルのほとんどを受け入れられる Microsoft の動向にひっそり注目するようになっていました。

元々 Microsoft に限らずクラウドの向こう側に興味関心はあったわけですが、たまたま中の人にお話を伺う機会があり、幸いにもオファーをいただけたこともあり飛び込むことにしました。
振り出しは国内でクラウド関連の仕事をすることになりますが、よりパフォームできれば場所にこだわらずにチャレンジしていこうと思っております。

今後ともよろしくお願いします。

あ、肉とか鮨のお誘いは引き続き歓迎いたしております。

ソフトウェアエンジニアだけでサービス運用できる環境を作って失業した話

はじめに

このエントリは非常にポジティブで技術的なチャレンジに関するまとめであり求人エントリでもあります。

まとめ

昨年後半から、急成長するサービスを支えるため “どオンプレ” な環境で作ったサービスをクラウドに持っていく仕事をしていました。

クラウドのオイシイところを押さえられるよう作り変えをした結果として “Infrastructure as Code” を実践することになり、結果としてソフトウェアエンジニアだけですべてがコントロール出来る状態になり、インフラおじさん業が不要になりました。

そういった環境で働きたい "腕の立つITエンジニア(特にスマホとサーバサイド)" を募集しています。

発表資料&箇条書きで振り返る最近の動き

AWS Casual Talks #3

  • https://github.com/myfinder/aws-casual-3/blob/master/slide.md
  • クラウドに移すことを決めて、opsリポジトリを作って色々まとめ始めた頃
  • この頃はまだAutoScalingとかやってなかった
  • 毎度インスタンスを差し替えるのではなく、Ansibleで継続的にconfigを更新するやり方をしていた
  • ログ集計をオンプレのHiveから、Redshift or BigQueryどっちでやるかを検討していた時期
  • セットアップが面倒なものをDockerで運用したら楽になるんじゃと思って使い始めたのもこの頃
  • 実際Docker使うと楽になった

AWS Advanced Users Meetup vol.2

  • https://github.com/myfinder/aws-advanced-users-meetup-2/blob/master/slide.md
  • このタイミングから、Ansibleを継続適用するのをやめ、イミュータブル方向に一気にかじを切った
  • デプロイを種サーバからでなくS3から行うようにしたのもこの頃
  • AutoScaling対応をして、弾力的なアプリサーバの運用ができるようになった
  • 結果として、いわゆる “Infrastructure as Code” を実践することになった
  • Mackerelの威力を思い知った
  • この時注意していたのは “必要以上にクラウド側特有の機能に頼らない(学習を必要としないようにする)” ということ、これが後々、別のソフトウェアエンジニアへの情報共有で重要なポイントになった

Mackerel Meetup #3 と Monitoring Casual Talks #7

  • https://github.com/myfinder/mackerel-meetup-3/blob/master/slide.md
  • ここでこれまでの総まとめ的な発表をした
  • モニカジ7では “インフラエンジニアが死んだ” というタイトルで失業した話をした
  • この頃には今までやらなくてはいけなかった仕事の大半がなくなった
  • この後は細かいチューニングやら、ちょっとイケてない部分や余計な手順を省く仕事をしていた

直近の改善

  • Dockerコンテナでデプロイしていた諸々をすべてPacker->AMIという形に変え、Dockerを使うのをやめた
  • この方がすべてのコンポーネントをソフトウェアエンジニアが把握しやすいというのが理由
  • DockerコンテナもPackerから作ることができるので、最初からDockerでやるよりも汎用的だし未来の可能性を狭めない
  • packer build時にServerspecを使って、セットアップ状況をチェックできるようにした
  • ピークとそうでない時のトラフィック差が大きいサーバは Spot Instance 使うようにしてコストを大幅に引き下げた
  • AutoScalingが走っている時にdeployすると、タイミングによっては古いコードのままサービス投入されてしまう問題があったのでデプロイロック機構を入れる
  • 更に増えていく機能やデータをうまいこと扱うため、DynamoDBとその周辺ツールセットの検証と引き継ぎ

結果

  • “どオンプレ” だった環境が下記のような技術要素に置き換わり、スケーラブルで、かつソフトウェアエンジニアだけでコントロール可能で柔軟さと機動力をあわせ持ったシステムに生まれ変わった
  • サービス監視/インスタンス管理をMackerelで
  • インスタンスのセットアップやAMI作成をPackerで
  • セットアップ状況の保証をServerspecで
  • トラフィックが上下する部分はAutoScalingで
  • 量の多いログ集計はBigQueryで
  • ほとんどコードで管理できるようになり、新しい取り組みにソフトウェアエンジニアがチャレンジしやすい環境ができた
  • かくしてインフラおじさんとしてやっていた仕事をおよそ無くすことができ、更に運用コストも大幅に減らすことができ、私は堂々失業することになったのだった

とても大事なお知らせ

このエントリにある取り組みをしたエム・ティー・バーン社のAppDavisというサービスはいま絶賛成長中であり、機能開発がとても活発です。

↑に書いたようなチャレンジにも大いに理解のあるチームで開発をしたい ”腕の立つITエンジニア(特にスマホとサーバサイド)” を募集しています。

ご興味、ご関心を持っていただけた方は気軽に 社長 に声をかけるか、 こちらのフォーム から "エム・ティー・バーンの話を聞かせろ" と送ると良いでしょう。

www.fout.co.jp

おわりに

丸2年エントリでも書いたことですが、自分がこれまで取り組んできたことで重要な点は “開発/運用の品質/スループットを上げつつコストや納期を勘案して、サービス展開の可能性を最大化する” ということだったように思います。

今回のチャレンジでは、振り返ってみると意識していた原則が2つあって "何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること” "ボトルネック以外触らない" というもので、それが結果として自分の仕事を無くすことにつながっていったわけです。

そういうわけで、今後はもっと違うことにチャレンジしていこうと思っております。今後とも何卒よろしくお願い致します。