MongoDB for Production,転ばぬ先の杖 ～Production Notesを読もう～
こちらは、クリエーションラインアドベントカレンダー2024 12/13の記事です。
この記事を書いている今は11月下旬ですが、公開されるころはすっかりクリスマスムードかと思います。昨年のアドカレを執筆していたころ1歳だった息子は2歳になりました（当たり前）。プラレールとトミカが大好きな男児に育ちました。今年のプレゼントとしてトミカタウンのおもちゃを用意してあります。喜んでくれるといいなあ。
今回は、MongoDBを本番環境で使う際に役立つ情報について、Production Notesを中心に紹介します。
本記事執筆のきっかけ
クリエーションラインはMongoDBの日本語テクニカルサポートを提供しています。弊社経由でMongoDBのEnterprise Advancedをご契約いただくと付帯します（詳細はセールスにお問合わせください）。なので、弊社のMongoDBテクニカルサポートをご利用するお客様＝MongoDBを本番環境でご利用いただくことが確定しているお客様がほとんどです。
テクニカルサポートをしていると、お客様の本番環境で問題が発生し「導入時に考慮していれば…」と感じるケースが少なくありません。これはMongoDBにかかわらずシステム屋あるあるかと思いますが、なるべく防ぎたいのが本音でしょう。
Production Notesを読もう
本番環境に導入する場合のノウハウや事前にチェックできるリストはないのでしょうか？結論から言うと、MongoDBの場合はProduction Notesがそれにあたります。
セルフホスト版とAtlas版、両方が用意されています。
セルフホスト（自己管理型配置）版
Atlas（MongoDB提供のDBaaS）版
このようなドキュメントは、ある程度成長してきたプロダクトであれば、公式で用意されていることがほとんどです。Kubernetesであれば「Production environment」がありますし、GitLabであれば「The GitLab Handbook:Production」「GitLab installation requirements」というドキュメントがあります。
「Best Practices for Production Environment」「Best Way for 〇〇」「minimum requirements 〇〇」というワードで検索をかければヒットしやすいかと思います。
なぜProduction Notesが活用されないのか
この記事を通して言いたいことは、「MongoDBを本番環境で使う場合、公式ドキュメントにあるProduction Notesやチェックリストをよく読み込んで、適宜本番環境に反映してください、以上」となります。
ここからはなぜ活用されないのか、活用するためにはどうしたらいいのかを考えてみることにします。
考えられる原因①：そのようなドキュメントの存在を知らない
昨今は、オープンソースのソフトウェアでもドキュメントが充実しているものがかなり増えています。日本語ができるコントリビューターが増え、日本語に公式で対応したドキュメントも多くなりました。しかし経験が浅く、日々の仕事に忙殺されていると、こうした情報にアクセスする機会が少ないのかもしれません。
この記事を公開することにより、Producution Notesが必要な方々に届いてほしいと願ってやみません。
考えられる原因②：ドキュメントを読み込む十分な時間が取れない
公式ドキュメントどれもそれなりにボリュームがあります。最初からスラスラ読める人はいないかと思います。（最初からスラスラ読める人は、きっとそのドキュメントを読まなくても、すでに知識がそれなりにある方というジレンマ…）
考えられる原因③：検証する環境や工数を確保できない
②と近いですが、初めて触るプロダクトというのは、「こういうものなんだな」という感覚をつかむまでは思ったより時間がかかるものです。
MongoDBでは、公式でチュートリアルが用意されています。見てみるとわかるのですが、なかなかのボリュームがあります。私も完走はしていません（しとらんのかい）。スタートガイドもありますが、データベース管理者(DBA)が必要な知識を身につけるには物足りないかなという印象です。
そこでクリエーションライン公式ブログでは、「はじめましてMongoDB」という記事を公開しています。
「はじめましてMongoDB #2 MongoDBを建ててみよう」では、データベース管理者（DBA)や、インフラエンジニアといったプラットフォームの保守担当に刺さるように意識して執筆しています。
最初の1歩を踏み出すためにお役に立てれば幸いです。
考えられる原因④：必要な設定を吟味できない
実は公式ドキュメントの内容をすべて適用しなくてもMongoDBは動きます。ハードウェアに関する考慮事項を満たせばほとんどの環境で動くでしょう。
問題が出るのは、本番環境でシステムの一部として稼働し始めて、しばらく経ってからです。ある程度データ量が増えたり、利用者が増えてくるとパフォーマンスの問題が出てきます。そういう状況になってから設定を確認してみると、推奨パラメータ値が設定されておらずそこで頭打ちになっていたり、そもそも非推奨の構成だった…ということがあります。
こういう事態を防ぐためには、設計や構築の段階で公式ドキュメントの内容を吟味し、システムの要件にあった設定を行うことが重要です。
限られた時間内で効率よく必要な情報を見つけ出すアイデア
↑の章で「設計や構築の段階で公式ドキュメントの内容を吟味し、システムの要件にあった設定を行うことが重要です」で〆ましたが、これが出来たら苦労はしませんよね 。(#ﾟДﾟ)ｺﾞﾙｧ!!
効率の良い情報収集を行う方法について、私が普段やっていることを少し紹介します。
①ツールを活用する
公式ドキュメントに行きついたものの、これを読むのには時間がかかりそうだ…というとき、要約してもらえると助かります。そういうとき、私はGoogleのNotebookLMを使っています。2024年6月に日本語にも対応したので、ご存じの方もいるかと思います。2024年12月現在ではGoogleアカウントがあれば使用可能です。
以下のスクリーンショットは、冒頭で紹介した公式ドキュメントのURLを情報ソースとしてインプットし、質問してみたところです。
NotebookLMの良いところは、情報ソース内でどこに根拠となる記載があるかをあわせて提示してくれるところです。回答横の数字をクリックすると、ソースガイドから提示してくれます。
もちろん回答を鵜呑みにするのは良くありませんが、まず質問して根拠を確認する…という流れを繰り返すことで効率よく情報を収集することができます。
②導入段階からテクニカルサポートを活用する
サービスインした後のシステムで、OSやサーバ、ストレージの設定や構成の変更を行うのが容易でないことは、サポート側もよく理解しています。
現状、サポートが設計や構成のご提案をすることはできません。（そういうサービスの場合、会社にもよりますが、「カスタマーサクセス」や「コンサルティング」という形で提供されるはずです）
ですが、「こういう設定をしたいんだけど、エラーが出て設定できない」「こういう構成をしようと思っているんですが、非推奨でしょうか？」という質問にはサポートが可能です。（後者はあくまで公式の方針に従った汎用的な回答となります）
目的地そのものを決めることはできませんが、目的地にたどり着くまでの落とし穴や遠回りを避けるお手伝いをすることはできます。サポートから的確な答えを引き出す方法については、以下の記事もありますので、こちらも読んでいただけると嬉しいです。
それでも公式ドキュメントをしっかり読み込んでほしい理由
①唯一無二のバイブルだから
やはり一次情報をあたるのが一番の近道です。QiitaやZenn、個人ブログなどのインターネット上のナレッジは大変便利ですが、他人を経由した二次情報に過ぎません。再現可能な手順や結果を詳細に記載している素晴らしい記事もたくさんもありますが、個人のメモに過ぎないものもあります。
参考にするのはかまいませんが、本番環境の設計や設定の根拠としてQiitaやZennや個人ブログ、Stack OverFlowを挙げるのはあまり好ましくはないでしょう。
②公式ドキュメントを読み解けるエンジニアは貴重だから
公式ドキュメントを読む重要性は理解しつつ、忌避感を抱く方はそれなりに多い印象です。私自身も公式ドキュメントを読む前には気合を入れます。
そういう人が多い中で、公式ドキュメントを読み解く能力（＝読解力）がある方は、頭一つ飛びでている印象です。そこから分かりにくい点・躓きやすい点を言語化し、書籍を執筆したり、インターネット上にナレッジとして発信したりできる方ならば、さらに重宝されてキャリアアップにもつながるかと思います。
読解力は鍛えることができます。最初は数分しか走れなかった人が、日々のジョギングを繰り返すことによって徐々に走れる距離が伸びるのと同じです。体力やスタミナという感覚に近いです。最初はしんどいですが、徐々にスピードが上がりますし、知識もつくので、早く読めるようになります。
明日（12/14）の記事はkodak_tmoさんです。どんな記事なのか楽しみですね。
