オペレーション | OpenStreetMap Blog

2024年、OSMFオペレーションワーキンググループ(OWG)はOpenStreetMap.orgにおけるOAuth 1.0aとHTTP Basic Authの機能を停止します。これらはアプリケーションがOSMウェブサイトまたはAPIでユーザー認証を行う技術的な方法です。OAuth 2.0がほとんどのシステムで標準的な認証方式となっているため、OAuth 1.0aとHTTP Basic Authは2023年から非推奨となっていました。

移行プロセスでの主要な日付は以下の通りです:

2024年3月1日: 新しいOAuth 1.0aアプリケーションの登録が無効化されました。既存のアプリケーションには影響はありませんでした。HTTP Basic Authには影響はありませんでした。
2024年5月1日: システム管理者がOAuth 1.0aまたはHTTP Basic Authを使用し続けているアプリケーションを見つけるためのブラウンアウトを開始します。
2024年6月1日: OAuth 1.0aとHTTP Basic Authがシャットダウンされます。

これらの認証方式の廃止は、セキュリティ上の懸念と、メンテナンスされていないコンポーネントに依存するなど多くの認証実装を維持する複雑さの低減のためです。

開発者にとってどのような影響がありますか？

OAuth 1.0aまたはHTTP Basic Authを使用してOpenStreetMap.orgウェブサイトにログインするアプリケーションの開発者は、OAuth 2.0に切り替える変更が必要になる可能性があります。幸いなことに、これは幅広くサポートされている業界標準です。

アプリケーションがAPIへの読み取り専用の呼び出しのみを行う場合、認証は任意です。レート制限の目的から、リクエストに認証を追加するのが望ましいですが、必須ではありません。OSMのログインを使用するWebサイトのアプリケーションであれば、OAuth 2.0の使用がはるかに簡単です。多くの他のサイトでも使用されているため、サポートが十分であり、ユーザーがウェブサイト上でたくさんのトークンを抱えてしまう問題も回避できます。

API経由で編集を行うローカルで実行されるソフトウェアを開発している場合、コードの変更が必要になる可能性があります。一般的な言語にはOAuth 2を扱うライブラリがあり、認証には常にライブラリを使うことが望ましい方法です。コマンドラインツール用にはZverikさん作成のライブラリを使うこともできます。またはシェルスクリプトを自作しても十数行で済みます。

ご利用の言語でのOAuth 2クライアント実装のサンプルをオンラインで見つけられるはずです。より詳細な情報が必要な場合や技術的な質問がある場合は、GitHubチケットをご利用ください。 OWGは、OAuth 2.0の使用に修正が必要なアプリケーションの追跡も行っています。

マッパーに与える影響

ほとんどのマッパーは変更を感じることはないでしょう。この移行はOSMアカウントへのログインやウェブサイトの使用方法に影響を与えません。iDとJOSMは以前からOAuth 2.0をデフォルトの認証方式としてサポートしています。HOTタスク管理ツール、MapRoulette、HDYCなどのサードパーティサイトにOSMアカウントでログインする場合も、これらのサイトはすでにOAuth 2.0に移行しているため影響はありません。読み取り専用のAPIアクセスであれば、認証は一切必要ありません。

The OpenStreetMap Foundation is a not-for-profit organisation, formed to support the OpenStreetMap Project. It is dedicated to encouraging the growth, development and distribution of free geospatial data for anyone to use and share. The OpenStreetMap Foundation owns and maintains the infrastructure of the OpenStreetMap project, is financially supported by membership fees and donations, and organises the annual, international State of the Map conference. Our volunteer Working Groups and small core staff work to support the OpenStreetMap project. Join the OpenStreetMap Foundation for just £15 a year or for free if you are an active OpenStreetMap contributor.

. ちょうど1年前、私はOpenStreetMapを支えるテクノロジーとインフラの信頼性とセキュリティを強化することを目標に、OpenStreetMap Foundation (OSMF) に参加しました。この1年間、私はボランタリの献身的なチームであるオペレーション・ワーキング・グループと密接に協力してきました。私たちは共に、作業プロセスや文書の改善において大きな進歩を遂げ、私達の集団としての有効性強化に到達することができました。私はグループによる支援とコラボレーションに極めて感謝しており、OpenStreetMapの未来のための強固な基盤を構築するため、私たちが実施しためざましい前進を目にできることを嬉しく思っています。

以下で、その内容について少し詳しく説明したいと思います。冗長性、監視、アクセス、およびドキュメンテーションの改善、タイルレンダリングのためのクラウドサービスの利用を拡大、AWSからの寛大なスポンサーの活用、セキュリティ対策の改善、開発環境の刷新を実施しました。

昨年の作業に関してより詳しい話を聞きたい方は、 State of the Map 2022での講演とGeoMobポッドキャストでのインタビューをご覧ください。そして、みなさんからの連絡も大歓迎です。 osmfuture@firefishy.comまでメールをください。

2022〜2023年におけるサイト・リライアビリティの詳細

私達のサーバのソフトウェア管理

小規模なインフラコンポーネントのコンテナ化（GitHub Actions for building)

私は “Configuration as code” 設定の一環として、以前はchefコードベースの特別メソッドを使用して構築されていた、小規模なサイトの多くをコンテナ化しました。また、ビルドのステップをGithub Actionsに移動させました。今後のコンテナ（”docker”）ベースのプロジェクトに必要となる基盤を構築しました。これらは、OSMFインフラストラクチャでホストされる、私たちの最初のコンテナ/Dockerベースのプロジェクトです。

chefベースのコードは、よりシンプルに、より安全に、そしてより速くデプロイされるようになりました。

chefテストの改善（OPSオンボーディングドキュメンテーション）

. 私たちは、すべてのサーバーとその上で使われるソフトウェアのインフラ（構成）管理にchef.io を使用しています。昨年、chefテストのキッチンテストが拡張され、最新のApple Siliconマシンでも動作するようになりました。テストは現在、CI/PRプロセスの一部として確実に実行されています。テストを行うことで、私たちが行う構成変更に対し、品質管理と保証が加えられます。ARMサーバのハードウェアに移行する前にテストキッチンを使用することができたこともあり、ARMサポートの追加はより簡易になりました。

信頼できるテストがあれば、新しいchefのコントリビュータが参加しやすくなるはずです。

ネットワークインフラの強靭化

アムステルダムのネットワークアップグレード（新しいスイッチ、デュアルリダンダントリンク。ダブリンにも順次反映予定)

アムステルダムのネットワークはこれまで、冗長性を確保するべき箇所に対応できていませんでした。CiscoのSmall Business装置が使われ続けており、ハードウェアの問題で予期せぬ停電に見舞われたこともありました。また、この機器は将来のアップグレード作業の足かせとなっていました。そこでオペレーショングループは、ダブリンのデータセンターで標準的に使用していたJuniper製のハードウェアに交換することを決定しました。ライブ環境でのダウンタイムを最小限に抑えながら（<）、機器を交換することができました。

ダブリンとアムステルダムの両データセンターでは、標準化された、よりセキュリティの高い構成が採用されています。各サーバーは、冗長性とパフォーマンスを向上させるため、完全に結合されたリンクを持つようになりました。スイッチは、電源とネットワークの冗長性が向上しています。来月には、完全な耐障害性のアップリンクの設置（発注済み）が予定されています。

両データセンターへの帯域外アクセス（4Gベース）

私は、各サイトに帯域外アクセス装置を構築し、設置しました。このデバイスは、シリアルコンソールを使ってネットワークと電源管理機器に直結されています。帯域外デバイスは、プライベート4Gネットワーク（1NCE）への弾力性のある4Gリンクを持っています。帯域外アクセスデバイスは、冗長電源と4xシリアルコネクタを備えたカスタムメイドのRaspberry PIです。

メンテナンスを容易にするインフラストラクチャの文書化（ラック/電源）

データセンターの各ラックユニット、電源ポート（Power Distribution Unit）、ネットワーク接続、ケーブルをドキュメント化しました。これにより、サーバの管理が容易になり、ミスが減り、リモートハンド（外部サポートプロバイダー）に適切な指示を出すことができるようになり、私たちの代わりにチャンスを作ってくれるようになりました。

Oxidizedの利用（ネットワーク機器の可視化）

ネットワークや配電の設定をgitに保存し、変更点を報告するようにしました。これにより、変更の見通しが良くなり、セキュリティも向上しました。

構成は継続的に監視され、サイト間で構成がずれた場合でも、解決が容易になりました。

Terraform Infrastructure as Code（管理・再現性の向上）

TerraformはInfrastructure-as-Codeツールです。現在リモートモニタリングサービス（statuscake）の管理に使用しており、AWSとFastlyのインフラの管理にも導入する予定です。

以前は、これらのコンポーネントはすべて、それぞれのウェブUIを使用して手動で管理されていました。Infrastructure-as-Codeは、運用チームが共同で変更作業を行うことを可能にし、可視性を高め、変更の再現性やロールバック処置を容易にします。

私たちは、dnscontrolコードを使用して、すべてのドメインのDNSを管理しています。 CIテストを追加して外部との連携を強化するなど、昨年から少しずつ改良を加えています。

クラウドサービスの利用拡大

レンダリングインフラにAWSを使用。AWSのコストを最適化を実施。セキュリティの向上。バックアップの改善。さらなるパイプラインの追加。

オペレーションチームは、数年にわたりAWSの利用を徐々に増やしてきました。私は、AWSのベストプラクティスガイドラインに従って、請求管理とセキュリティを改善するために、AWS組織モデルを使用し、複数の用途別AWSアカウントを構築してきました。レンダリングインフラを拡張するために、AWSのスポンサーシップを惜しみなく獲得しました。私たちは、AWS Graviton2 EC2を使用して、ARMアーキテクチャを使用した実験的な新しいレンダリングインフラを構築しました。
これまでARMベースのサーバーを使用したことはありませんでした。chef（configuration as code）の改良の一環として、Apple Silicon（ARM）のローカルテストサポートを追加していましたが、ARMサーバーに必要な互換性をchefに追加するために必要なのはわずかな作業だけでした。

OSMタイルレンダリングスタックを実行するためのAWS Graviton2 EC2インスタンスのパフォーマンスには感銘を受けました。また、AWSでレンダリングスタックをさらに改善するために、オンデマンドスケーリングとインスタンスのスナップショットをテストしました。
データバックアップ目的でのAWSの利用も増加しています。

セキュリティの向上

昨年、多くの一般的なセキュリティが改善されました。例: サーバーへのアクセスはsshキーで行うようになりました（パスワードによるアクセスは無効になりました）。また、運用チームが使用していたgpgベースの特注パスワードマネージャーから、gopass （https://www.passwordstore.org/ の機能豊富なバージョン）に移行しました。gopassは、鍵の管理とパスワードストアの共有を改善します。

さらに、インストールされているコンポーネントを減らし、インラインアップデートを無効にし、XMLRPCアクセスを無効にすることで、WordPressインスタンスのロックダウンを強化しました。また、アクセス権を持つユーザーを減らし、使用されていないアクセス権を削除する作業も行っています。

改善を要する脆弱性に関し、主要な領域をドキュメント化（冗長性、セキュリティ、その他）

技術的な脆弱性についての文書化: 改善が必要な脆弱性の主要な領域（冗長性、セキュリティなど）に関する報告書を作成しています。この報告書をもとに、将来的に投資を集中し、リスクへの暴露をさらに減らしていく予定です。

開発者環境の刷新

新しい開発サーバ

昨年、すべての開発ユーザを新しい開発サーバへ移行させました。旧サーバーは耐用年数（～10年）を迎え、容量（CPUとストレージ）の限界に達していました。新しいサーバはアムステルダムのデータセンターに直接配送され、現地作業員によって物理的なラッキングが行われた後、私が作業を行い、すべてのユーザーとプロジェクトを移行しました。

Subversionの引退

私は昨年、古いsvn.openstreetmap.org のコードリポジトリを引退させました。このコードリポジトリはプロジェクトの発足当初から使われており、プロジェクトにおけるコード開発の豊かな歴史が含まれていました。私は reposurgeon をカスタマイズした設定で使用し、 svn コードリポジトリを git に変換し、完全な貢献履歴を維持したまま、以前の貢献者（350人以上）をそれぞれの github や関連アカウントに正しくリンクするよう注意を払いました。古いsvnのリンクは維持され、現在はgithubのアーカイブにリンクされています https://github.com/openstreetmap/svn-archive https://github.com/openstreetmap/svn-archive

フォーラムの移行

旧フォーラムの移行では、100万件の投稿と16年分の投稿をdiscourseに移行しました。すべての投稿は、fluxbbのマークダウンからdiscourseのマークダウン記法に変換されました。すべてのアカウントを統合し、認証をOpenStreetMap.org の”シングルサインオン”ベースの認証に変更しました。

すべての古いフォーラムのリンクは、ユーザー、カテゴリー（国など）、スレッドトピック、そして個々の投稿など、正しいコンテンツにリダイレクト（インポートされたものへのリンク）されました。