先週、LinodeのスポンサーシップでMongoDB World 2022に参加しました。この記事では、私が参加したときのことを、今後のチュートリアルのために取り組んでいるコードスニペットと一緒に紹介します。また、MongoDB World での体験をまとめたビデオも作りました。
私の240字要約
MongoDB Worldは、私がもっとMongoDBを使う必要があると確信させてくれた。講演のほとんどは(私の講演も含めて)開発者が好むような技術的な深さには達していなかったので、対象は開発者よりも管理者だったのでしょう。参加することをお勧めします。
所在地ニューヨーク
ジャビッツ・センターのロケーションは完璧で、会場も素晴らしいものでした。カンファレンスには、ニューヨークのような都市はまさにエネルギーが必要です。外ではいろいろなことが起こっていて、それが自然にカンファレンスにも伝わってくる。
評価9/10
キーノート
イベントのキックオフとして、MongoDB CEOのDev Ittycheria氏の話を聞いた。もし私が聞いた基調講演がDev氏のものだけだったら、MongoDBをもっと頻繁に使おうという気になったかもしれません。Devは、MongoDBはチームがより少ないコストでより多くのものを提供できるようにするために存在するという概念を強調し、カンファレンスにいる間中、これは真実であるように思えました。
そのあと、別のプレゼンターが登場し、会場のエネルギーを吸い取った。その様子は手に取るようにわかる。Devは、分科会が始まる前にステージに戻り、必要なエネルギーを与えてくれた。
また、基調講演ではMongoDBの素晴らしさを紹介するライブデモもいくつか行われました。ご想像の通り、ライブデモはしばしば災いの元となりますが、私が見た限りではスムーズに行われました。
初日の午後、CTOのマーク・ポーターは、私がこれまで直接見た中で最高の技術基調講演を行った。彼は、第一に教師であり、第二にCTOであることは明らかです。彼の雰囲気はサーフキャンプのインストラクターのようでしたが、彼のスキルは、経験豊富なデータベースの専門家であり、技術的に言えば、世の中の大半のCTOの周りをぐるぐると回ることができるものでした。もし、私が1つだけ講演を聴くとしたら、それはマークのキーノートだったでしょう。
最終日の基調講演を聞いて、本当に興奮しました。レイ・カーツワイルです。レイ・カーツワイル氏は熟練した未来学者であり、そのキャリアの中でいくつかの素晴らしい予測を行ってきました。また、ベストセラーを数冊執筆し、講演も数多く行っています。
MongoDB Worldで、Rayは私が何年も聞いてきたことを繰り返した。今思えば、これはそれほど驚くべきことではないのですが、RayはDevやMarkのような人にインタビューされて、基調講演の締めくくりにダイナミックな会話をするべきだったという結論に達しました。
評価7/10
ブレークアウトセッション
分科会では、各チームが組織でMongoDBを活用するためのさまざまなツールやテクニックについて、興味深い概要が紹介されました。
ここでは、私が非常に興味深いと思ったトピックをいくつか紹介します。
- レルム
- サーバーレスMongoDB（アトラスサーバーレス）
- 時系列
レルム
Realmは、モバイルデバイスやIoTがマネージドMongoDBクラスタ（AtlasやLinode Managed Databasesなど）とデータを同期できるようにする、非常に魅力的なサービスだと思われます。
エッジにおけるデータの課題は、ローカル/オンデバイスのデータベースとクラウドのデータベースがしばしば同期していないことを確認することです。一見すると、これは些細な問題に思えるかもしれませんが、10万台のモバイルデバイスのような規模になると、この問題は大きな問題になり得ます。
まだ試していませんが、私が参加したセッションでは、MongoDBのRealmがエッジからクラウドへのデータベース同期に伴う様々な問題に対する完璧なソリューションであることは確かです。
Realmの主な利点をいくつか紹介します。
- MongoDBへのダイナミックなデータシンクのために作られた
- SQLite/コアデータの置き換え
- デバイスのフットプリントが小さい
- クロスプラットフォームAPI（Kotlin, Swift, JavaScript, etc.）
- モバイル/IoTデバイスの接続問題への対応を支援します。
詳しくはこちらをご覧ください。
サーバーレスMongoDB
サーバーレスという言葉は、私に言わせれば、サーバーレスを "マネージドスケールホスティング" と考える傾向があるので、ちょっと馬鹿げています。名前に関係なく、サーバーレスはここにとどまり、私はそれに大賛成です。
サーバーレスとは、コンピュート・リソースをどれだけ大きくても、どれだけ小さくても、需要に応じてスケーリングするプロセスです。どの程度の規模かはしばしば議論されるところですが、ゼロまでスケールダウンすることで、多くの場合、リソースやドルやセンスの面で多くを節約することができます。
サーバーレスのメリットを強調するためのシナリオを並べてみましょう。
サーバーレスシナリオ。あるウェブサイトは、スポーツイベントの際にリアルタイムで統計情報を追跡しています。
スポーツイベントが開催されているとき。ウェブアプリケーションには大量のアクティビティトラッキングデータがあり、ファンの数、時間帯、シーズン中のポイントなどに応じてウェブアプリケーションのトラフィックが変化するため、イベント全体を通してウェブアプリケーションが高速である必要があります。
スポーツイベントが開催されていないとき。ウェブアプリケーションはアクティビティトラッキングを行わず、ウェブアプリケーションはほとんどの時間、トラフィックがゼロになります。
イベント間の時間がどんなに長くても、上記のことはほぼ間違いない。この理論的なウェブサイトの動作のばらつきは、サーバーレスがなぜ素晴らしいかを示す劇的な例です。ある瞬間、10万件のリクエストがあり、次の瞬間には8件のリクエストになります。次の瞬間は25万リクエストで、その次は76リクエストです。サーバーレスは、こうしたシナリオを優雅に、そして驚異的なレイテンシーで処理するように設計されています。
サーバーレスデータベース。つかみどころのない夢
上記のシナリオはサーバーレスなWebアプリケーションでうまくいきますが、サーバーレスなデータベースも同様にどうでしょうか。
サーバーレスであろうとなかろうと、現代のウェブアプリケーションには、できるだけ低いレイテンシーでデータにアクセスする能力が必要です。データベースがサーバーレスであれば、稼働しているインスタンスがゼロになるようにスケールすることができ、また単純にデータベースをオフにすることができます。そのため、データベースをオフにした場合、再びオンにするには遅延が発生します。したがって、データベース層でのサーバーレスは従来から非常に困難でした。
データベースのスケールアップやスケールダウンの問題は、データのサイズに起因しています。歴史的には、Kubernetesや様々なDockerの実装により、アプリケーションがサーバーレスになる一方で、データベースサービスを常時稼働させておく方がずっと簡単で摩擦もありません。
Atlas Serverlessがやっていることに匹敵するServerless SQLの代替はまだ見たことがなく、これはMongoDBチームの小さな成果ではありません。彼らがサーバーレスデータベースを開拓したのは素晴らしいことです。
オープンソースのサーバーレスMongoDBのサポートは見当たりませんでした。おそらくそれも来るのでしょう。
サーバーレス。スピード、コスト、フリクション
アプリケーションのデプロイが速ければ速いほど、何がうまくいって何がうまくいっていないのかを知ることができます。サーバーレスは、この種のテストを最小限のコスト増で行う能力を解き放ちます。これは、サーバーレスを使う最大の利点の1つであると私は主張します。
アプリが動作していない場合は、そのままにしておきますが、実行中のリソースはゼロにします。トラフィックの最初の兆候があれば、需要に応じて拡張します。需要がなくなったら、規模を縮小する。これは、A/B広告テストを行うことと完全に一致します。これにより、アプリは必要なときに動作し、常時動作するわけではありません。
アプリが正常に動作している場合、継続的な負荷を維持するためのオーバーヘッドは、さまざまなマネージドサービスによってチームから切り離されます。つまり、小規模なチームであれば、ほとんど（あったとしても）余分な作業をすることなく、驚くほどの量の負荷を処理することができるのです。
これらすべては、サーバーレスがチームの有効性を高めると同時に、そのアプリケーションの需要要件を処理するためにかかる全体的なコストを削減することを意味しています。
サーバーレスはすべてに完璧なソリューションではありませんが、リソースに制約のあるチームの多くの問題を解決してくれることは確かです。
MongoDB上の時系列
MongoDB (少なくともバージョン 5) には、時系列分析を行うための組み込み関数があります。時系列データの作成に慣れていなければ、単にデータベースのコレクション (テーブル) のすべての行に何らかのタイムスタンプを追加する作業です。
時系列解析はこんなことに最適です。
- 売上予測、製品需要、交通量予測などを必要とする財務上の意思決定を改善する。
- 株式・債券等の購入
- センサーやIoTデバイスを時系列で追跡。
- パフォーマンス指標（Webサイトのパフォーマンス、広告など）
この種の分析にはもっとたくさんのアプリケーションがありますが、時系列データの利用は組織内の多くの役割にとって重要です。MongoDB を使うと、この分析がとても簡単になります。MongoDB を使った時系列分析についてはこれからたくさん触れますが、ここでは MongoDB とPython pymongoパッケージを使った簡単なサンプルをお見せします。
1.MongoDBクライアントを初期化する
import os
from pymongo import MongoClient
# this assumes you have a running MongoDB cluster/instance
mongodb_un = os.envion.get("MONGODB_USERNAME")
mongodb_pw = os.envion.get("MONGODB_PASSWORD")
mongodb_host = "localhost"
mongodb_port = 27017
db_url = f"mongodb://{mongodb_un}:{mongodb_pw}@{mongodb_host}:{mongodb_port}"
client = MongoClient(db_url)2.時系列コレクションの作成
# create/select a database
db = client.business
# create time series collection
db.create_collection(
"rating_over_time",
timeseries = {
"timeField": "timestamp",
"metaField": "metadata",
"granularity": "seconds"
}
)3.モック時系列データの追加
from datetime import datetime, timedelta
from random import randint
# Insert a lot of fake time series data
names = ['Kitchen','Animal','State', 'Tastey', 'Big','City','Fish', 'Pizza','Goat', 'Salty','Sandwich','Lazy', 'Fun']
company_type = ['LLC','Inc','Company','Corporation']
company_cuisine = ['Pizza', 'Bar Food', 'Fast Food', 'Italian', 'Mexican', 'American', 'Sushi Bar', 'Vegetarian']
_count = randint(0, 10_001)
for x in range(1, _count):
now = datetime.now()
delta = now + timedelta(days=randint(0, 2), minutes=randint(0, 60), seconds=randint(0, 60))
if randint(0, 1) == 1:
# randomly vary the direction of the timestamp
delta = now - timedelta(days=randint(0, 2), minutes=randint(0, 60), seconds=randint(0, 60))
random_company_index = randint(0, (len(company_cuisine)-1))
business = {
"metadata": {
'cuisine' : company_cuisine[random_company_index],
'name' : names[randint(0, (len(names)-1))] + ' ' + names[randint(0, (len(names)-1))] + ' ' + company_type[randint(0, (len(company_type)-1))],
},
'rating' : randint(1, 5),
"timestamp": delta
}
#Step 3: Insert business object directly into MongoDB via insert_one
result=db[db_name].insert_one(business)4.時系列集計を行う
# run an aggregation
list(db.rating_over_time.aggregate([
{"$unwind": "$metadata"},
{"$project": {
"date": {
"$dateToParts": { "date": "$timestamp" }
},
"rating": 1,
"cuisine": "$metadata.cuisine",
}
},
{
"$group": {
"_id": {
"cuisine": "$cuisine",
"month": "$date.month",
"day": "$date.day",
"year": "$date.year",
},
"avgRating": { "$avg": "$rating" }
}
}
]))という結果になります。
[{'_id': {'cuisine': 'American', 'month': 6, 'day': 16, 'year': 2022},
'avgRating': 2.75},
{'_id': {'cuisine': 'Italian', 'month': 6, 'day': 12, 'year': 2022},
'avgRating': 3.0},
{'_id': {'cuisine': 'American', 'month': 6, 'day': 14, 'year': 2022},
'avgRating': 3.0655737704918034},
{'_id': {'cuisine': 'Pizza', 'month': 6, 'day': 15, 'year': 2022},
'avgRating': 3.0508474576271185},
]このデータは私がPython と MongoDB を使って実験したものですが、MongoDB 時系列分析を使って過去の価格から株の購入を自動化するというセッションに大きく影響されたものです。このセッションは技術的に深く掘り下げたものではありませんでしたが、上記のように、その必要はなかったのです!MongoDBは確かに素晴らしいことをするための摩擦を減らしてくれるようです。
レビュー
全体的に、分科会のセッションは、私が開発者として本当に楽しんでいる技術的な深みに欠けていましたが、これは理にかなっていました。ほとんどのセッションは1時間以内で、30分ということもよくありました。聴衆のバックグラウンドが多岐に渡る中で、このような短時間で技術的な詳細の核心に触れることは困難です。
私が参加したセッションで発表された内容は、あちこちでハズレがあったものの、概ね優れていました。
評価8/10
パートナーパビリオン
パートナーパビリオンには、MongoDBを業務で使う（使わない）企業に対して、関連サービスを提供する企業が集まっていました。これらのブースを担当しているのは、組織の意思決定者を対象とした営業担当者であることが多い。
ここでは、Linode とアカマイのチームメンバーにより多く会う機会があり、彼らとつながりを持つことができました。つまり、私たちのコミュニケーションのほとんどはインターネット上で行なわれており、彼らの顧客の多くがそうであると想像されるように、彼らとつながることは素晴らしいことでした。私は確かに偏見を持っていますが、Linode とアカマイのチームは信じられないほど親しみやすく、オープンで、あらゆるアイデアのブレーンストーミングに積極的だと感じています。
私が話を聞くことができた主要な企業をいくつか紹介します。
- HashiCorpです。Terraform のメーカーとチャットして、より多くの人に DevOps をより良く、より簡単にするための彼らのコミットメントを聞くことができたのは素晴らしいことでした。私はTerraform の現状をとても楽しんで使っていますが、未来は明るいようです。今後のHashiConfのイベントもチェックする必要があるかもしれませんね。
- Vercelです。Next.jsのメーカーは、最近発表されたAtlasとの統合のため、キーノートで大きく取り上げられました。いずれ、Next.jsだけでなく、彼らのプラットフォームにももっと時間をかけてみたいと思います
- MongoDBユニバーシティ。教育がMongoDBの戦略の大きな部分を占めていることは明らかで、需要のある、実用的で市場性のあるスキルを通じてアクセス可能な、教育の未来に大いに期待しています。
- Datadog（データドッグ）。ログの解析をクールにするのは誰だ？それはDatadogです。私はデモに参加させてもらいましたが、本当によかったです。この会社についてもっと知る必要があります。
一般的な評価
キーノート（前述）。7/10
- 素晴らしいスピーカーもあれば、物足りないスピーカーもある
ブレイクアウトセッション（上記で詳しく説明）。8/10
- 全体的に素晴らしいセッションだったが、開発者として楽しむ技術的な深みに欠けた。
チュートリアル6/10
- 私が参加したメインのものでは、無線LANの問題がありました。なぜ有線イーサネットのバックアップをしないのか？
- 講演者の問題処理は素晴らしかったが、内容は少し遅すぎたという結果になった。
食品： 3/10
- 2日目にホットドッグ？そうなの？
- 会議場から3ブロックのところにある素晴らしいピザ。
ファミリー向け：3/10
- 5歳以下の子供がいる場合は、0/10です。
- 人気のある観光地を除けば、小さな子供たちが楽しめる場所はほとんどない。
- ニューヨークは混んでいて、うるさくて、歩行者は攻撃的に歩き、車は非常に攻撃的です。
- 私はテキサス州オースティン近郊の小さな町に住んでいるので、この評価はそれを基準にしています。ニューヨークはそうではありませんが、私たちにはたくさんのスペースがあります。
場所：9/10
- プロフェッショナルの立場からすると、ニューヨークでのイベントは信じられないほど素晴らしいものです。素晴らしい料理、レストラン、バー、会場などがたくさんあり、他のプロフェッショナルを楽しませ、コネクトすることができます。
- NYCのエネルギーは、世界中のほとんどの場所で比類がありません。常に何かが建設／再構築され、人々は常に外出し、ほとんど常に何か美味しいものがあります。
- ニューヨークで15マイルが車で2時間以上かかるというのは驚きです。人によっては、これで立地評価を3/10に下げてしまうかもしれません。
- もし、私がスポンサーとして参加しなければ、ニューヨークは何でも高いので、評価は2/10（はぁと）です。
ホテル：5/10
- 狭い部屋なのに高い。
- また、私が宿泊したホテルの朝食ビュッフェはとても美味しく、他のホテルでも同じようなことを聞きました。
- 選択肢が多いこと。
空港3/10
- JFK空港のターミナル8は絶対に避けてください。ターミナル8は荒廃しており、食事や土産物の選択肢は乏しい。
- 空港からの出国は、多くの選択肢があり、どれも比較的短時間で済みます。
- もし、正しいターミナルに着陸したら、6/10に跳ね上がるかもしれませんね。
交通の便7/10
- Uber/Lyft/Taxi/etc、どこにでもありますね。
- 交通費が必要な時にコストがかかる。
- 空港までの交通費は、結局、航空券の1/4近くになってしまった。
- ニューヨークはとても歩きやすく、移動が簡単です。
会議のスナック6/10
- 良い選択、少なすぎ
カンファレンスドリンクセレクション。5/10
- 基本的にコーラのビッグ3製品。
会議用コーヒー：8/10
- 現地で淹れたコーヒーも美味しかったですが、やはり私はどこでも淹れ立てのブラックコーヒーが好きです。
会社の出番。6/10
- 20社くらいは来てくれるだろうと思っていた。
スワッグ3/10
- 賞品のための借り物競走？かわいいけど、遠慮します。
会議エンターテインメント：8/10
- パビリオンではピアノのデュエリングコメディアンがいました。彼らは最高でした。
- ゲーム大会があるようだが、一度に参加できるのは数人に限られるようだ。
- IDEAラウンジの司会は最高でした。
- アフターパーティーも参加された方々は楽しそうでしたね。
聴覚的なアクセシビリティ。
- イベントには、少なくとも3人のASL通訳者が必要な場所で働いていました。
- 品質については申し上げられませんが、素晴らしいものであったようです。
視覚的なアクセシビリティ。該当なし
- 視覚障がい者向けのサポートは探していないし、見てもいない。
当然ながら、人によって体験は千差万別なので、上記の内容はあくまで参考としてください。salt.
総合評価8/10
MongoDB Worldで、私はMongoDBを使う時間を10倍から100倍に増やす必要があると確信しました。私のキャリアの多くをSQLとそれを統合したツールに負っている私にとって、これは決して小さなことではありません。
MongoDB Worldは全体的に楽しかったので、もし能力があれば、2023年の参加を検討したほうがいいかもしれません。もし時間がないのであれば、1日目だけでも参加すると多くのものを得られると思います。もし参加されたとしても、イベント終了後にオンデマンドでいつでもセッションを視聴/再視聴できます（最大30日間と思います）。2日目、3日目も盛りだくさんの内容でしたが、2日目の午後から参加者が減ってきました。
カンファレンスでは、すべての技術的な専門知識を提供することは難しいと思いますが、MongoDB Worldはこのバランスをうまくとっていたと思います。多くのプレゼンターは、セッションの後、より深い議論に応じることができ、それは素晴らしいことでした。私が参加したプレゼンテーションのほとんどは、期待に違わず、プロフェッショナルで、よくできたものでした。参加者は、この分野で他の人々が何をしているのかを知りたいと心から思っているようでした。
ニューヨークのジャビットカンファレンスセンターは素晴らしく、イベント全体の雰囲気に壮大な印象を与えていた。その壮大さは、私の小さなホテルの部屋がいかに貧弱であったかを如実に物語っている。
しかし、ニューヨークの街角には、世界でも有数のグルメスポットが点在しています。もしあなたがグルメなら、ランチタイムにハドソンヤードやタイムスクエアに出かけてみてはいかがでしょうか。そして、他の会議と同様、コーヒーが飲めました。
もし、あなたがカンファレンスに参加している間、家族連れを考えているならば、考え直した方がいいかもしれません。
私にとってこのイベントのポイントは、参加者がビジネスの中でMongoDBをどのように使うのがベストかを教えることです。この点で、私はMongoDBを完全に信頼しています。忘れてはならないのは、SQLが初めて登場したのが1974年で、MongoDBの最初のリリースが2009年であることです。この時代の違いは、クラウドファーストの組織やプロジェクトが直面する現代の問題を解決するMongoDBのモダンなアプローチによって明らかになりました。このカンファレンスが存在するという事実だけでも、MongoDBがこの分野を前進させ、私たち全員を巻き込んでいこうとする献身的な姿勢を証明するものです。
MongoDB World 2023では、もしかしたらお互いに会えるかもしれませんね。
Cheers !
Justin Mitchel
教師＆創設者
CodingForEntrepreneurs.com
コメント