地質研究者が苦労しながら運用する 情報公開システムの実例 1 内藤一樹 産業技術総合研究所 地質情報基盤センター 2025/3/15 JAWS-UG茨城 × Education-JAWS コラボ回 

2 自己紹介 内藤 一樹 • 静岡県清水市出身 • 専門： 地質学・地球科学 • 産業技術総合研究所 鉱床、地質図幅 地質情報の利活用 

3 • 地質情報について • データの公開 • システムの運用 • データの永続性 内容 

4 • 地質情報について 

産業技術総合研究所 5 地質調査所 計量研究所 電子技術総合研究所 物質工学工業技術研究所 生命工学工業技術研究所 産業技術融合領域研究所 資源環境技術総合研究所 地質 計量標準 エネルギー ・環境 生命工学 情報・人間工学 材料・化学 エレクトロニクス ・製造 2001～ 産総研について 旧通商産業省の研究機関が統合再編されて発足 7つの研究領域 通産省工業技術院 統合 再編 

6 地質調査総合センターの地質情報整備の歴史 1885年発行 『二十万分一伊豆圖幅』 2005年公開 『20万分の1日本シームレス地質図』 地質調査調査所（GSJ）による最初の地質図 「二十万分一伊豆圖幅」発行 日本初の全国版地質図 「百萬分一大日本帝國地質圖」 1/7万5千 地質図幅 1/5万 地質図幅 1/20万 地質図幅 コンピュータ編集による日本地質図 20万分の1日本シームレス地質 1885 1952 1955 1990 2005 1922 1899 1882 地質調査所発足 （現 産総研地質調査総合センター） データ配信 ウェブサービス デジタルデータ インターネット 明治15年 143年 2025 ↑日本人技術者による パリ万博出品 古い資料も現役 （地質分野の特徴） 

7 • 地質図 各縮尺の地質図幅、海洋、水理、火山、環境... • 資源の情報 油ガス田、炭田、鉱物資源... • 防災に関する情報 活断層、噴火活動、津波堆積物... • 地盤の物性 岩石物性、標準試料... • 地球物理・化学情報 重力、地殻応力、化学組成... • 文献情報 地質文献... • 地球科学に関する知見 など 産総研の「地質情報」 

8 植生 表土 地層 研究者が徒歩で調査して作成 20万分の1スケールの例 斎藤眞ほか(2007) 屋久島地域 5万分の1スケールの例 斎藤眞ほか(2005) 九州中央部「砥用(ともち)」地域 ・表土の下にある岩石や地層の種類・分布・相互関係を地形図上に示した地図． ・植生や建造物，表土などは無視 「地質図」とは 

9 土木・建設の資料 防災の資料 5万分の1「末吉」 5万分の1「谷汲」 5万分の1「立山」 5万分の1「須磨」 ダム(中岳ダム) 橋(明石海峡) 活断層 (濃尾地震の震源断層) 大崩壊地 (立山) 活断層 (立川断層) 5万分の1「青梅」 地質図の活用場面 

10 資源開発の資料 5万分の1「三条」・「長岡」 5万分の1「近江長浜」 5万分の1「宮原」 5万分の1「末吉」 採石 天然ガス 地熱発電 石灰石 地質図の活用で「新たな探鉱・探 査の可能性」や「調査期間の短縮」 が期待できる 5万分の1「戸賀及び船川」(第2版) 石油天然ガス 地質図の活用場面（２） 趣味、レジャー、教育 学校の自由研究 など 社会全体に役立てる情報 

11 • データの公開 

12 産総研のデータ公開 研究情報公開データベース (RIO-DB) 研究過程で蓄積された有用なデータを知的基盤としてインターネット上に公開 AIST Today 2004.7より 分野別DB数 公開DB数とアクセス数推移 1996 2001 Research Information Database: RIO-DB 

13 RIO-DBの終了  研究領域ごとの運用へ 産総研全体で運用されていたRIO-DBの終了に伴い、 データベースは研究領域ごとの運用に移行することに  地質領域は、AWSを選択 1996 2009 2013 2025 2001 RIO-DB （オンプレ） 産総研全体の運用 地質領域 地質情報データベース （クラウド・AWS） 研究領域での運用 地質領域の体制では、オンプレの運用は困難 • システム専門家がいない • 場所がない （東日本大震災後に地質のサーバ室廃止） • 装置維持が困難 （修理・維持、時間のかかる購入手続き） • 常時運用が困難 （2日／年の停電・停止） 日本の国内法が適用されるサービス、 国内データセンターが望ましい 連続運転 節電 東京リージョン 

14 産総研 地質領域（地質調査総合センター）の公開データベース 活断層 海底 標本 衛星 地質図 地層名 火山 物性 約30の「テーマDB」 

15 活断層 

16 地質図 

地質調査総合センターのウェブサイトで発信する情報は、原則として二次利用可能 政府標準利用規約（第2.0版） GSJの公開データベース API ダウンロード 地図配信 データ配信 17 

18 • システムの運用 

地質情報基盤センター サーバ管理 19 地質領域でのDB運用の前提条件 • 共有サーバに、複数のテーマDBが相乗り • テーマDBは、それぞれの研究グループが管理 （構築、コード安全性確認も含め）  RIO-DB時代にはSEによる手厚いサポートがあったが、基本なしに • 検証システムと公開システムで構成 （セキュリティの確保） • 公開データのみ （機密性なし） テーマDB: 研究グループ管理 テーマDB: 研究グループ管理 テーマDB: 研究グループ管理 運用の役割分担 体制の差 

20 運用開始の頃の構成 検証系VPC Amazon S3 AIST Internet 公開系VPC Amazon EC2 Amazon EC2 Security group Security group 研究者がテーマDB構築 静的な公式サイト （CMS） SEのみ 産総研からの接続のみ 動的なテーマDB 

21 共有サーバのイメージ テーマDB1 テーマDB2 テーマDB3 テーマDB4 PostgreSQL PHP MySQL Tomcat S3 bucket S3 bucket S3 bucket EC2 instance contents テーマDB別のディレクトリ テーマDB別のS3バケット 共通機能 

22 10年以上運用を継続した結果 生じてきた問題 • OS更新 • PostgreSQL, MySQL, PHPなどの更新 • アクセス増加による負荷 対応（場当たり的な） • 新OSのサーバへテーマDBを移行 （未完了なもの多数） • ALBによりテーマDB毎に、旧OSサーバ、新OSサーバへ振り分け • CloudFrontの導入 （可能なものについて） テーマDBごとの対応の差が大きい 遅いものに合わせる結果、問題が拡大 

23 最近の構成 検証系VPC Amazon EFS Application Load Balancer Amazon S3 AIST Internet Amazon CloudFront 公開系VPC Application Load Balancer Amazon EC2 Amazon EC2 Amazon EC2 Amazon EC2 Amazon EC2 Amazon EC2 ・地図タイルなど ・静的な公式サイト ・動的なDBサイト 旧OS 現行OS 次期OS Security group Security group OS別にサーバが増加 サーバ移行作業の利便性のためにEFSを使用 …… サーバ増、コスト増 

24 ALBの利用 旧OS 現環境OS 次期OS EC2 instance contents テーマDB1 テーマDB2 テーマDB3 テーマDB4 PostgreSQL PHP MySQL Tomcat EC2 instance contents テーマDB1 テーマDB2 テーマDB3 テーマDB4 PostgreSQL PHP MySQL Tomcat EC2 instance contents テーマDB2 テーマDB3 テーマDB4 PostgreSQL PHP MySQL Tomcat a a a a b b b b c c c c Application Load Balancer テーマDBごとに移行作業の対応・進捗が大きく異なる  テーマDBのOS移行状況に応じて、サーバに振り分け バージョンの異なるPostgreSQLなど PHPも 現状、 一部だけ移行成功 ほぼ作り直しのもなど 

25 研究者がテーマDBを管理することからくる問題 • DB管理に無関心 （論文が最優先） • システムに無関心 ftpでデータを置くだけ。 サイト作成などを業者任せ。 • 引継ぎ問題 アクティブな担当者が退職した後、引き継いだ担当者が無関心 （研究者の特性： 他研究者の領域を侵さない） • 単発のデータ公開にとどまり継続性に難 プロジェクトなどの要請で作ったものの、継続体制が弱い • 独走する データ公開に積極的すぎて、承認プロセス抜きでデータ公開しようとしがち • できるだけシンプルな環境を提供 • 作業環境を変えない 成果公表のわかりやすいルール化が必要 

26 さまざまな問題 些末な問題 • 開発テストのためにPostgreSQL, PHPなどの別バージョン追加の要望 テストの残骸（？）が増えたままに • 複数バージョンのPostGIS、全文検索エンジンの利用要望 • テーマDBの旧バージョンも残して利用を続けたい要望 運用中によく起こる問題 • OOMキラーによる巻き添え被害 メモリを考慮しない計算処理（アプリケーションの設計の問題） 複雑なSQL（アプリケーションの設計の問題） • データ取得APIへの大量アクセスによる障害  巻き添えが起きない環境、コンテナ、オートスケーリングやLambdaの検討 も必要 所内向けデータとして利用  ほんとうはルール違反 自分用の計算プログラムをそのまま流用 無茶な日本語検索 活用してもらえるのは良いが、サーバ への配慮がない利用者がよくいる 負荷テストとかしていないAPI でも、管理の複雑化、コスト増は避けたい 

27 部分的なコンテナ導入 テーマDB1 テーマDB2 テーマDB3 テーマDB4 PostgreSQL PHP MySQL Tomcat S3 bucket S3 bucket S3 bucket EC2 instance contents Container 13 PostgreSQL 16 テーマDB Amazon ECS 将来的には ECS (or EKS)へ ・課金、運用管理の手間のバランスを考慮 コンテナ化しやすい部分から導入試験中 

28 データベースシステムのこれから 産総研で たびたび言われる（要求される）のは、 「データ公開は進んだから、今後はDXをがんばって」 と言われても、地質屋にできることは「データ整備」「データ提供」 データ整備： 機械可読、解析可能なデータの整備 データ提供： データ連携に必要な最低限の機能を整備 データカタログ、データ提供API整備  社会に地質情報を浸透させることで、安全・安心な社会を実現 Amazon API Gateway 

29 • データの永続性 

30 長い目でみたデータ提供 地質情報は100年後でも価値がある情報 一方、ウェブサービスはサーバ維持費や組織体制の変化によって停止や廃止の リスクがある データ提供の継続性のためには 「システムとして維持」 ではなく 「成果物の公表」 を土台としたデータ整備 地質情報の公開データベースのあるべき姿 データの継承： • データ出版物として公開リポジトリに登録 （doi 大切） • メタデータ、データフォーマットの標準化 • 統合データセット （linked data も） 利便性： • データ検索・提供API （機械にやさしい） • 目的・用途別の可視化ウェブサイト （人にやさしい） 100年後にもデータを継承すること その時々のニーズに応じて 永続性 データの自立性 

31 紙出版 アプリ サービス 公共リポジトリ ファイル 永続性 利便性 維持コスト 継承 DX 情報の永続性・保存戦略 クラウド・AWS 

32 永続性 利便性 OSS活用 枯れた配信技術 HTTP + 静的ファイル (CSV, JSON, RDF…) XYZタイル, WMTS, WMS CKAN 最小限のREST風API 無理しない技術レベル doi uuid リポジトリ 紙出版 RDF 産総研 予算 人員 技術レベル 制約 継続性▲ • 組織のリソースに制約がある中で、可能なレベルのサービス構築 • オフラインでの長期保存も考慮 メタデータ メタデータ 地図配信 運用コスト データを返すのみ LODのデータ構造 と永続識別子 標準化 将来のデータ復元 図書館 公共 データの自立性の確保 オープン 情報の永続性・保存戦略 

33 オープンフォーマット 仕様の公開されたフォーマットで保存することで、将来の互換性とデータの生存率を向上 用途 フォーマット（例） 地質図（ベクトル） GeoJSON Shapefile FlatGeobuf 地質図（ラスタ） GeoTIFF 数値データ CSV JSON / XML （構造化データ） NetCDF （大容量、時系列） SEG-Y （地震探査） 文書・図面 PDF XML メタデータ DCAT （データカタログ向け標準） ソフトウェア依存を防止 Linked Data で管理されるリソース 再利用性 機械可読性 情報の永続性・保存戦略 

34 ありがとうございました