2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
リンクをコピー
記事をブックマーク
増井雄一郎氏:プログラミング言語はそれぞれ得意なことが結構違います。例えば、英語だといろんなことを直接的に伝えるのが得意だったりしますし、日本語は情緒的なことを伝えるのが得意だとよくいいますね。同じように、プログラミング言語にもそれぞれ得意・不得意があります。
どうしてそういうことが起こるのかというと、(スライド内)ここに人がいます。先ほどコンピュータを「小人さん」って言いましたが、小人さんの職業で一番わかりやすいのはシェフだったりします。
じゃあ、プログラムというのは何かというと、仮に「何かご飯を作ってください」ということだとします。「小人さんをどう動かしてご飯を作ってもらうのか」という指示書がプログラムになります。そうすると、シェフは何にもなくても……。
(説明イラストに対して「雑!」との声)
僕の画力ではこれくらいが限界なんですよ!(笑) ちなみにこの資料ができたのが5時ぴったりなので、1時間前まで僕はひとりでこれを描いていました。
……まあ、実際には「ご飯を作ってください」と言われても、何もなしでは当然ご飯は作れないわけですよね。ご飯を小人さんに作ってもらうためには、包丁や材料が必要だったりします。
この包丁とか魚にあたる部分が、「OS」とか「ライブラリ」と言われるものです。これらもプログラムです。
包丁と魚を持ったまま「ラーメン作ってください」みたいなことを言われても、それは無理だって話になります。そうすると、ひとつの方法は「自分で開墾して小麦を育てて収穫して……」
と全部自分でやるというものがあります。自前で全部作る。小人さんは結構働き者なので、言えば何でもやってくれます。畑を耕すところからでもできる。でもものすごくマニュアルが膨大になります。なにせ開梱の方法から書かないと行けないわけですから。
まあ、普通はそんなことしないで、麺を買ってきて茹でて作ります。場合によっては「インスタントラーメンを買ってくる」っていう方法もあるんですね。プログラムは自分で書かなくても誰かが用意したものを持ってくる事ができます。
ラーメンを作るなら、それにあった道具と材料を持ってくればいいわけです。
問題は「どこから持ってくるか」という話しですが、そのお店に相当する部分が、OSと言われる部分です。例えばAndroidで言えば、「Android」というお店からしか、これらの材料を仕入れられないんですね。なので、Androidという仕入れ屋さんから仕入れたものしか作れないということになります。
同じように、iPhoneの場合は「Apple」というお店から買ってきた具材からしか何かを作れない。それぞれ結構入っている具材が違うので、同じ小人さんが動いているとしても「iPhoneではできるけどAndroidではできない」と(いうことがある)。
同じ指示書でも、Appleではいきなり「インスタントラーメンを買ってきてお湯をかければできます」みたいなことが書いてあるんですけど、Androidでは場合によっては「ラーメンはないので小麦から育ててください」ということがあります。
そういうふうに、同じ小人さんに動いてもらうんですけど、プラットフォームによって指示書の書き方が全然違う。実際にできてくるものもすごく違う。だから、それぞれでプログラムを使い分けなければならない。iPhone向けに作ったプログラムはiPhoneでしか動かないし、Android向けに作ったプログラムはAndroidでしか動かない。そういう問題を引き起こしています。
じゃあ、部品をもっと共通化すればいいじゃないか。「どこのお店でも必ず包丁は売っています」とすればいいじゃないか、というのを人類……僕らプログラマーはここ20年くらい何度も試みてるんですが、実際にはうまくいってないんですね。
さらにプログラムというのは、先ほどの「包丁」とか「魚」を、AppleやGoogleから提供を受けたり、また全然違う会社から買ってきたりします。例えばトレタマネージャーのグラフを作る機能は、「グラフを作る」という素材(魚)を売ってる会社から買ってきてるんですね。
それをやると、すぐグラフが作れるようになります。ただ、その魚が結構腐ってる場合があるんですよ。なので、Appleが「この魚を使えばすぐできるよ」と言ってるから試してみたら魚が腐ってたとか、包丁が切れないとかそういうことがあって、僕らはよくダマされます。
このようなOSやライブラリを組み合わせて、ご飯を新しく作る。そのための指示書がプログラムです。実際にトレタはどうやって作りはじめたかというと、初めにいきなり指示書、レシピを作るということはないわけですね。「何を作りたいか」、例えばラーメンが作りたいとか、作りたいものを想像するところから始めます。
トレタの場合は、トレタの前に同じようなアプリケーションがなかったので参考にするものがない。一番楽なのは、よくあるんですけど、どこかから出来合いのものを持ってきて「まったく同じものを作って」と言うとすごく簡単なんですよ。見たことないものじゃなくて、料理だったら「カレー」とか。それと材料を渡して「作って」と言うと、結構誰でも簡単に作れる。
そういうものがないので、一番初めには……これは多分2013年だから2年前くらい?
代表取締役・中村仁氏:まだミイル(料理写真共有アプリ)をやってた頃だね。
増井:そのときに仁さんが描いたトレタの青写真、「できあがったらこうなります」というものです。
中村仁氏:青写真だから(ペンの色を)青くしたの。
増井:(笑)。で、こうやって描いて「こういったものを作りましょう」という企画書みたいな感じで作ったんですね。これ、「2012年」って書いてますね。3年前の2012年に、こういうものを作ろうという「ゴール」を決めたんですね。
これを小人さんに実現してもらうために、僕らはマニュアルを作りましょう。じゃあ「ここの項目はどういうふうに表示するのか」とか、「入力項目はどういったものがあるのか」とか、どんどん細かく細分化していった。先ほど言ったように、一番最初はこういうざっくりしたものなんですが、最終的には「手を3cm前に出して……」みたいにすごく細かい指示書まで書き起こしました。
今、トレタは1つじゃなくて大きく2つのプログラムで動いています。それが「サーバ側」と「クライアント側」と僕らが言っている、2種類のプログラムです。皆さんが普段お使いのほうは、iPadのアプリケーションと、近々リリース予定の「トレタマネージャー」というアプリケーションです。実は、皆さんが直接触ることができないし見ることもできない、サーバにあるアプリケーションというのがあります。ちなみに、それぞれ誰が作っているのかという写真を貼ってみました。
iPadのアプリケーションは、先ほど言ったようにネットワークに繋がないと動かない。どうしてこうなっているかというと、iPadに入力してネットワークに繋がらないと、iPadにデータを全部溜めてしまって他の人が見たりすることができないし、iPadを落としたらオシマイになってしまう。なので、iPadではなくもっと別の場所にデータを保存してセキュリティを高めて、不正にアクセスできないようになってるんですね。サーバはそういった門番みたいな事と、データを保存する場所ということになります。
この通信はほぼ電話だと思ってもらっていいんですけど、iPadの中の小人さんがサーバに電話をして「今日の予約一覧をください」と言うと、サーバの中の小人さんが……今7台あるので7人いるんですけど、小人さんが探してきて答えてくれる。で、iPadからサーバに電話をかけるんですけどコールセンターみたいな仕組みになっていて、直接小人さんが答えるんじゃなくて答える専用の人がいるんですね。そこの人たちのことを「API」といいます。
僕らがよく言う「APIサーバ」というのは、電話を受けるほうの口、電話を受ける人を作ってるんですね。このAPIは、決められたことしか答えられないんです。人間みたいに柔軟にできていない。先ほど言ったように言われたことしかできない小人さんなので、「レストランの今日の予定をください」と言っても「『今日』の意味がわからないです」みたいになる。なので、「6月○日の○○店のデータを全部ください」というふうに細かく指定する必要があります。
そういったやり取りの仕組み、取り決め。「何を言ったら何を返してくれるのか」というそのものをAPIといいます。サーバの中には、APIの後ろにたくさんの小人さんがいるんですね。例えば「6月3日の予定をください」と言うと小人さんが慌てるわけです。(イラストで)小人さんが1人死んでるんですけど、ときどき死ぬんですよ。これがね、意外に死ぬんです。
(会場笑)
年に1人くらい死ぬんです。そのうちの1回がこの前です。基本的には、この人たちは誰か1人が死んでも他の人たちがカバーするようになっています。だけど何人かだけはすごく大事な人がいて、その人が死ぬと共倒れになるという司令塔みたいな人がいるんですね。
こういうのを死なないようにしたりとか、死んだやつを掘って埋めたりするのが佐野っち(開発チーム・佐野裕章氏)になってきます。
(会場笑)
もう少し噛み砕いていうと、今は7人でやってるんですけど、この先もっともっと店舗が増えてきたら、ここを10人20人にしないとダメなんですね。そうすると、もっといろんな管理が複雑になっていく。
小人さんはデータを処理するんですが、もうひとつ問題があって。ものすごくたくさんの仕事を速くこなせるんですけど、まったく記憶力がないんです。だいたい数字を10個くらいしか覚えられないんですね。それ以外はどうするかというと、「データベース」と呼ばれる書庫みたいなところにみんなで書き込んでいくんです。そういう構造になっています。
APIから電話がかかってくると、小人さんはデータベースからデータを引っ張って、それを集計してiPadのアプリケーションに教えます。あ、今リザベーションのテーブルってどれくらいのレコードあったっけ? ……今だと数千万件くらいのレコード、予約件数を扱ってるんですね。
いくら小人さんが速いといっても、例えば「今日の予約一覧を取ってきなさい」ということで数千万件を一から見直していくと、さすがに数分〜数十分かかっちゃうんです。そういうふうにしないために、データベースは「インデックス」という仕組みで最初に整理をして保存してるんですね。レストランごとに保存して、レストランの中では日付ごとに保存して……というふうにしています。
僕らエンジニアが「こんなデータ取れますか?」と言われたとき、「ちょっと難しいです」ということがときどきあります。というか、まあまああるような気がするんですけど。それは、「レストランごと」「日付ごと」というふうに整理して保存しているところに、「100人以上の予約を取っている店が何件あるか調べたいんです」と言われると、結局店舗(のデータ)をごっそり取ってきて一から全部調べなきゃならないんですね。そうすると、すごく時間がかかってしまう。
コンピュータはデータ件数が多いと、(調べる)前に準備をしておく必要があります。こういったことも(予測して)プログラムを作るんです。先ほどの画面を見たときに「じゃあこういうデータの順番で並べておこう」とか、そういったことも考えてプログラムは作る必要があります。
もうひとつ、ウチの会社で忘れてはいけない言葉で「AWS」と「クラウド」というものがあります。クラウドっていうのは何なのかとよく言われるんですが、これは実はマーケティング用語で、深い意味は別にありません。いろんな意味を持ってるんですね。
先ほど言ったサーバという特殊なパソコンは、ウチは今Amazon社から借りています。Amazon社はオンラインの本屋さんでもともと始まったんですけど、あそこもECのサイトをやるためにたくさんサーバを買って、それをうまく運用してるんです。死んだやつを早く埋めたり、死んでも大丈夫なようにたくさんさらってきたりとか、そういったことをいろいろしていて、いろんな会社が同じことをやっているので、それを商売にしたらいいビジネスになるんじゃないかということで始めた事業です。
Amazon社はサーバを山のように買って、さらにこんな感じで山のように積み上げて。Amazon社は写真を公開していないのでこれはGoogle社のクラウドなんですが、これが普通に体育館10個分とか、20個分とか。それが世界各地にあり、たくさんサーバを立てていますが、僕らはこれを見ることも触ることもできません。
なぜかというと、クラウドというのは「雲」なんですが、僕らは雲の向こうにあるものを意識しない。それより前の時代はパソコンと同じで、自分でパソコンを買って箱を開けて線を繋いでインストールしてもし壊れたら修理に出して……と全部やる必要があったんですが、それをAmazon社やGoogle社が見えないように勝手にやってくれる。
新しく買ってきて箱に入れるというのも全部向こうがやってくれて、プログラム1つ……さっき言ったAPIですね。要するに電話みたいなものひとつで、「今から1000台サーバ使いたいんです」と言うと、ものの5分で1000台くらい用意してくれる。こういった仕組みのことをクラウドといいます。その中でいま世界で一番メジャーなのがAWSなんですね。
それ以外にも、結構各社出してます。例えばGoogle社がGoogleクラウド(Google Compute Engine)を出していたりとか、マイクロソフト社が「Azure」というのを出していたりします。日本のメーカーも出してるんですが、まともなものは今のところないですね。というのも、どうしたって規模の世界なんですよ。
たしかGoogleが去年1年間で買ったサーバの台数と、日本全体で買った分でいうと、Google一社で買ったほうがはるかに大きいと言われています。そういうふうに、世界のベンダーと日本とでは規模感がぜんぜん違っているんです。
Amazon社やGoogle社はかなり堅牢なシステムを提供しているのですが、それでも小人さんが死んだりします。ごくたまにAmazon社のサーバにアクセスができなくなったりする事があるんですね。過去には数時間使えなかったこともあります。それで一緒にトレタも止まってしまうと大変困るので、複数のクラウドサービス、具体的にはAWSとGoogle Cloudの両方にデータを置くようにしています。
これだとAWSが全滅してもGoogle Cloudからデータの読み出しができる様になります。こういう風に複数のクラウドを使う事を「マルチクラウド」といいます。まだここまでやっている会社は多くなくて、私たちも試行錯誤しながら進めている所です。
こういったことをいろいろ考えてプログラムを作ってますね。特に怖いのは……(スライドが)見えづらいですかね。「スペランカー」の絵が入ってるんですけど、プログラムは1点間違えると即死するんですよ。先ほど言ったように、プログラムというのは指示書なんですね。指示書に間違ったことを書いていると、どんなにアホなことでもそのとおりに小人さんは実行します。
例えばSQLというプログラムで「DELETE FROM reservations; WHERE restaurant=1;」って書いているんですけど、「レストランが1のものの予約を全部消しなさい」という意味で書いたのですが。これをよく見ると、僕が入力ミスをしちゃってここにセミコロンが入ってるんですよ。これが入っているだけで、全社分の予約が一瞬で消えます。ゼロコンマ何秒の世界で、全予約が消えます。プログラムはこうして1文字間違えるだけで、即死します。
去年、京都でCTOと呼ばれる技術責任者が集まった会合みたいなものがあったんですが、そこにCTOが100人来たんですね。「こういうミスでデータを全部消したことがある人」って聞いたら、結構いました。みんなやりすぎだと思うんですけど(笑)。こういうふうに一歩間違えると僕らはたぶん死んでしまうので、こういうことが起こらないようにするために、プログラムが書いてあるのに何度も検証したり、皆さんにテストしていただいたりしています。
逆に、もうひとつおもしろいことがあって、「プログラムを正しく書いてあるか」というのを小人さんにチェックしてもらうという方法があるんですね。小人さんにレストランを予約してもらって、ちゃんとメールが返ってくるかというのを、小人さんを動かすこと(で確認)ができる。
小人さんを動かすためにはどうするかというと、プログラムを書くことなんですね。プログラムを確認するためのプログラムを書く。僕らはそういうのをテストプログラムと言っているんですが、そういうふうになってます。
そのテストプログラムがあっているかどうかわからないので、そいつをさらに検証するためのプログラムを……とやると永遠に終わらないんですけど、まあそういうことはしません。僕らはこのテストプログラムという形で、そんなことが起こらないように実際にプログラムを動かしてみて、正しいかどうかというのを日常的にいろいろ確かめています。そういうのを入れていくと、5万行とかすごい量になってきます。
もうひとつ、僕らが間違える以外に問題があって、先ほど言ったようにこれら(プログラム)の部品というのはAppleなど外部から買ったり、「オープンソース」といって誰かが無料で配ったものを使ったりしています。それの中身が動かなかったり、Appleさんが言ったように動かなかったりして、そういうのに僕らも右往左往してたりします。
プログラムというのは、小人さんにどういった具材を与えて、それによってどんな料理を作ってもらうかという指示書になります。それをどんどん書いていくと、こういったアプリケーションができる。僕らはだいたい2週間に1回、新しいバージョンを作ってます。だいたい2週間ペースなんですよ。
2週間のうちで、どんな新しい機能を実装するかという青写真を作っていって、それを見ながら「マニュアルに書き換えるためにはどこにどういう影響があるのか」とか「実際にこのときはどうするんだっけ」というのをみんなで確認したり、場合によっては皆さんに「こういう場合はどういうふうに動いたほうがいいですか」と聞いたり。
マニュアルを書き進めていくと、「こういう場合はどうすればいいんだっけ」と思うことが結構あるので、そういうのを確認しながらどんどん深掘りしていきます。それを全部書き終わるとアプリケーションとして動くので、皆さんに使ってもらったり、プログラムを書いたあとに「それが本当に正しく動くのか」を検証するためのプログラムを書いたり、というのを日常的にやっています。
そういったわけで、一周回ってきました。トレタというアプリケーションはクラウドの上で動いてます。サーバサイドはRubyという言語で書かれていて、トレタマネージャーはJavaScriptで……皆さんがお使いのブラウザの上でもプログラムは動くんですね。それについてはJavaScriptという言語で書いています。APIという口があって、iPadのアプリケーションは常にそこと話をしています。それはサーバの上で動いていて、データベースというところにデータを全部記録しています。
こういったプログラムのことを「クライアント・サーバ型」のプログラムというんですが、これはほとんどのネットワーク型アプリケーションがこうなっています。Facebookもそうですし、皆さんがお使いのSlackもそうです。こういったものが、同じような仕組みで動いています。
皆さんはたぶん、プログラムといってもなかなか取っ付きにくいと思います。実際に見えないものなので何かわからないと思うんですが、マニュアルだと思ってもらうと概ね正しくて。それを僕らがどうやって、文字抜け等の間違いをなくして、正しく動くものを作っていくか。もし間違ったとしても、どうやってデータが全部消えないようなマニュアルを書くか。そこは文章力の問題のようなものですね。要するに、変な解釈をされない文章をどう書くかという話に近いんですが。そういったものを駆使してプログラムを書いています。
こういった形で、トレタというアプリケーションを日常的に作っています。可能な限り、普通の人にわかるように説明してみました。
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦
2024.12.11
大企業への転職前に感じた、「なんか違うかも」の違和感の正体 「親が喜ぶ」「モテそう」ではない、自分の判断基準を持つカギ